 A couple of things before we get going. IT for IT and accelerated delivery. A few things that Craig mentioned earlier on. It's business first. And it's also about the change, the rate of change that is really created by people in the organization. So we're going to have a look at both of those as we progress through the slides. So a little bit about us. I'm from Panagia Training in Singapore. We have a sister company over in Cambridge in the UK. And you can have a look at this quickly. And I'll move on. So the problem is getting worse in IT. We heard earlier about bimodal IT. How many of you are familiar with bimodal? How many of you like Gartner? OK, there we go. I think some of the points that Craig made with regard to speed are quite important because, in fact, where I come from, I don't agree with bimodal. I think what you have is speed that is generated by the IT division, or the IT division's ability to deliver measurable benefit to the organization. Now, that might change as you go through. But of course, in order to do that, you have to have the right structures in place. And of course, QIT for IT, because that provides us quite a nice view of the value chain approach to understanding everything from one side in terms of your strategy all the way down through to your DTC, detect and correct, and of course, everything in between. So the problem for us then is trying to bridge the gap between what we have at the bottom there. We've got budget, which may be being depressed, certainly not going up in huge amounts across a lot of the companies that we work with. We've got our ability to deliver in IT. Now, this comes directly from the IT for IT book. And I certainly suggest, for those of you that haven't had a look at it, have a look at it. Of course, what we've got to do is try and address the IT management gap as things change quickly, whether it's cloud, whether it's microservices or otherwise. We have to keep up with business requirements, changes in business, whether they're local across different jurisdictions or otherwise different types of client and customer groups. So we've got to try and address that gap where the face is. And this is part of what IT for IT is trying to help us deliver by looking at the structures in place and the value chain. So where do we start? Well, we try and get a bit of common sense, which isn't always as common as it might sound. Figure out what we really want to do with accelerator delivery. Now, I haven't described why I'm talking about accelerator delivery. Quite simply, we're working with a client recently. We're looking at some of the structure from IT for IT overlaid on accelerated and agile techniques, reduced the turnaround time from 108 days to 24 days. Now, this makes a huge difference in your organization's lifecycle. You can generate and create measurable benefit quickly if you understand how you generate benefit or value and you have the right structures in place. So that's really the hook into why it's accelerated delivery and IT for IT. Of course, starting, it would be useful to know something about IT for IT. And as Rob said, we're looking at 2.1 and there's ongoing work in the forum on IT for IT. Understand the useful bits. It's a framework in a way, much like any other framework. And reference architecture, there are things that are going to be more useful than others to you. So focus in on those that you think will provide benefit to the organization. Treat it like your favorite uncle. Listen to it. It'll tell you some good stuff, but you wouldn't want him to move in and live with you, would you? So you just want to try and pick out the bits that are useful. IT for IT, there are a lot of useful bits as well. Always remember, of course, that you're not alone out there. There are other organizations, other people, that have gone down this route and similar routes that have done aggressively agile, accelerated delivery, traditional IT for IT type approaches, and got them right. So again, and you've also got all of IT for IT behind you as well. So choose your next set of actions wisely. You can either stay calm or you can panic. A bit of both might help as well, because panic helps you focus the mind. Being calm, you can sometimes sit back a little bit too much. So what are our imperatives as we go down the back end of 2016 into 2017, 2018? Focus on IT to deliver the services that make us more competitive, that give us measurable benefit. I use the term measurable benefit rather than value, because as soon as you talk about value, you've got to describe what kind of value it is. And the assumption from an earlier discussion is that if you can measure it, then it should be better. It goes without saying that there are changing technology environments, more aggressive demands by not only the organization itself, but by more militant customers, regulators, legislators, et cetera. So of course, we've got to be able to address these in the normal state of affairs. Now looking at being able to address things quickly, we often hear about agile. And agile sometimes gets the same in equal and opposite, or so I'm looking for disadvantage or wrap, as Togaf does, and completely the opposite end. People often say Togaf is way too big for large organizations, but agile is only at the one end. And we can't scale that. Well, you can scale agile if you think about it. And the point I'm making here is that agile is largely a set of techniques for the right-hand side. So your right-hand side over here, for doing your coding, doing your peer-to-peer, peer-to-peer type of programming, doing your XP, your scrums, and things like that, sprints, et cetera. What happens if we could take the learning from that and pull it all the way across, all the way up to your S2P, your strategy to portfolio in IT for IT? Well, this is pretty much what we did. And I'm going to take you through an example from a gas distribution network where we went through this scenario. So what we're trying to say here very briefly is that accelerated delivery takes us from the strategic thinking side of things, looking at the portfolio of activities we need to undertake to actually deliver right at the other end, but also to continuously deliver, to have the right organizational structures in place, and also to allow those to adapt as necessary. I'm working with a client at the moment who is going through a huge transformation. And they're looking at reorganizing the business. So the first thing they've started out doing is setting up org charts. And you can be pretty sure that as soon as the ink is dry, those org charts will be out of date. So what do you need to do, again, thinking through IT for IT, is look at structuring your organization around where the decisions are made. Suddenly, it makes a lot more sense. A little bit more about that as we go. A multi-sourced service economy. The power is going into our customers into the traditional business side. With a credit card, you can buy all sorts of services that IT would otherwise take years to deliver. We've got to learn how to integrate these, how to consolidate, collaborate across different types of environment. So again, we do need to consider the future. Equally, so expect things to change with regard to expectations on the IT division as well. And in a way, it's, is IT any different to business? Nowadays, largely speaking, IT is the business in many organizations. And the business is IT. So we leave that for another day. And expect to manage change, but also to continuously improve. Again, a common theme, if you look through the four value streams, certainly the top three in IT for IT. So the obvious here is big projects. So we have a long spin-up. And we have this cumulative risk that grows with the project. And eventually, we'll deliver if we deliver on time. And of course, when you look at these big types of projects, it's always cost, time, and quality, and stuff like that. And without going back into TOGAF and looking at the transition architectures in phase E, which, of course, we can learn a lot from as well. Thinking back to how we can create an environment where we can deliver on businesses or the business requirements quickly and allow the organization to fulfill their requirements easily as well. And again, for those of you familiar with IT for IT, you'll start to recognize where these words sort of slot in. Of course, we have a delayed delivery. We also have at the, oops, let's go back one. It's going to go back. Back. How do we go back? There we go. Difficult people transition in this sort of big bang approach. And of course, when things do go wrong, we have big restarts. We can't afford that anymore. So again, what we want to try and do is move to a situation where we have short spin ups. We accelerate the delivery all the way from the strategy through the portfolio, manage the portfolio correctly, look at prioritizing on an ongoing basis from an exec, all the way through to a user level. Have the right structures in place, the right methods and approaches. And then start to deliver incrementally. Again, I've put up these strategic transitionals because architects like to see that sort of thing. But again, you can start to see that we can manage our risk. But we also need the structures in place. And again, if we look at the full value chain areas from IT for IT, you can start to see where some of this starts to make sense. So the IT business response. And by this, I mean a direct reference to IT for IT because you're looking at the business of IT in IT for IT. Basically, trying to professionalize what we do. We need to understand the business model. So this is very much an external focus. How does the organization create value? How do we capture that in our strategy through to our portfolio process? Once we've done that and we've got to a point where we understand that, we start to look at what that drives. Well, that drives our internal operating model. Now, we can develop our operating model and base it on how we deliver benefit to the organization. Suddenly, that changes the way we're going to structure things because it's not based on a traditional org chart anymore. You're looking at changes all the time. So you need a structure in place to actually make sure that we can deliver in a changeable environment. And then finally, we look at the engagement model. How do we engage with our clients, with our customers, be they internal or external? So again, suddenly, the way that or the business of IT suddenly changes. And of course, there's going to be a continuous loop between the understanding a changing operating model and the actual engagement model. And remember, we'll be engaging within, across the organization, and potentially outside the organization's borders as well. So IT for IT reminds us of a couple of things. Firstly, that the approach that we're taking today is very much about planning the big projects, as they say, a planned economy, bottom up, tactical approach, et cetera. What we want to do is to be able to understand the strategy and manage our investment in technology all the way through that. So understand the portfolio, prioritize, continuously prioritize the backlog. Again, for those of you that have been in the agile world or the accelerated delivery you'll start to see, even IT for IT itself has started to bring in cunningly some of these ideas. And where we're actually going is towards a more market-based economy in IT, because what we want to do is basically understand how we can deliver benefit quickly. In order to do that, you don't take a bus. You get something a bit quicker, smaller, more agile, things that turns corners more quickly. So again, IT for IT is already taking us down that route. What are the typical challenges that we see in trying to make IT actually work without IT for IT helping us? Well, the blurring of the line between business and IT. So credit cards and web services, cloud services, have allowed the business to become a lot more powerful. Sometimes usurping the power of the IT division. IT has got a change as well, from a technology and project-centric approach to a service-centric approach. So looking at the whole everything we're familiar with UX. We're familiar, someone mentioned earlier on this morning about CX, the whole customer journey and experience. We want to bring that in, because that changes. And it changes more and more quickly. If we look at the age of the average IT user and the ability, that's gone right down. And of course, people expect more from their IT, whether it's their personal IT and smartphones or corporate IT. We also have to respond to being more transparent about our costs. How many of you have been involved in companies where they've married a 10-year contract to a huge outsourcing deal? I won't ask for names, but I certainly won't ask how well those have been working in the past. We don't typically kill people in IT. It's a pity in a way, because we'd be a lot more careful about our planning and what we did. So having said that, other things that we want to consider, we are getting our budget squeezed a bit, but the demand isn't. The demand is increasing. So again, we need to understand everything from what the business does to deliver benefit through to making the right decisions, to building the right things, to making them available through fulfillment, and then making sure that we can proactively manage any issues, changes, problems, et cetera. Now again, there lies a very quick description of IT for IT. So some accelerated delivery principles. These aren't really Togaf-type principles with basic ideas. Simplify, standardize, and share. So coming back to being transparent. Continuous improvement with partners, colleagues, et cetera, not to them. Remember, we're all in this journey together, because we're creating things that improve the position of our organizations in their respective industry sectors, hopefully. So we're delivering measurable benefit, hopefully. Improvement is incremental. Again, we either wait for the one big bang and hope it works, or we improve incrementally. But again, we need the structures and the ability to do that. We've got to have that in place. Our customer specifies our value, or the value it wants, not us. So again, the locus of control is outside of IT now. Not that it was ever really in IT, because we're always doing things for other people. But we have to be a bit more careful, because the other side of the fence, as it were, is actually a lot more powerful nowadays. Capabilities define what our organization does, not how it does things. So we've got to figure out what the IT division does, or the IT department, whatever you call it, the IT portion of the organization. So again, understanding the drivers, the external drivers, all the way through to how we address those inside the IT world. However, here's probably one of the most challenging questions you can ask, if either your exec or your programs is, what do we want to finish first, rather than what we want to start next? IT is very good at starting things, because let's face it, it's a lot more fun starting new stuff, looking for new toys, et cetera, than finishing a project. So what we want to do is turn it around and start. Instead of looking for, let's have a look at this whole wave of things we need to do. Let's look at the things in that wave in terms of what has to be finished first. Now, in order to do that, they should link up to our strategy. Of course, some organizations say we don't have a business strategy, or it's not made available to us. And of course, those are challenges that you have to address on the floor as well. OK, client example, gas distribution network. Very briefly, what happened in this organization, as I said, they had a new CIO who was a bit of a lateral thinker. And in the last 18 months, basically what he did was turn around a very old-fashioned IT department into one that was agile, accelerated, and basically worked along the lines of IT for IT, except he didn't know that it was called IT for IT. So what he did was he looked at how IT created value for the organization, essentially looking at the value streams. Again, much like IT for IT, but he looked at it slightly differently. But the basic principles and the approaches were exactly the same. And what they did was they did away with things, with any term that used the word program and project. Because what they said was that as soon as you've got a project, you're already limiting yourself. Because Prince says that a project is a defined start date and an end date. Once you've got an end date, that's it. Now, change out in the world doesn't stop. It's continuous. So why don't we create the organization that maps to that change? So have the continuous improvement from understanding our strategic positioning, understanding what our portfolio should consist of, creating the right things, making them available for fulfillment in the organization. Not on our terms, but their terms. So what they eventually ended up with, as I said earlier, was a 180-day turnaround, which is kind of about average from what I've seen in these sorts of organizations. And this is a SAP-based organization down to 24 days across the board. That's pretty good. In fact, there were some other stats that showed that some of the business colleagues asked them to stop delivering on some projects because they couldn't take on board the change quickly enough, although there were only a couple of occasions there. Now, what do we mean by accelerated delivery? Basically taking some of the agile principles, Kanban approaches, boards, et cetera like that, and build them into the whole process from the beginning through to the end. And it's actually a lot simpler than you think. Except, of course, or maybe one or two people in the corner that might say, what about architecture? We still do big architecture, don't we? How many of you have heard of the concept of the architectural runway? Anyone? OK. Basically, this is a way of addressing continuous change in smaller chunks in an accelerated manner by doing just enough to keep the architecture in place. Now, that gives us the freedom from three-year planning, 24-month planning, et cetera, getting everything done in the architecture space, where you just have enough of the capabilities necessary to do what you need to do in a changing environment. Someone said earlier on that good enough is good enough. And that's a pretty good dictum when we're looking at accelerated delivery. It doesn't have to be excellent because you can waste time being excellent. It's got to be good enough to do the job. Good enough doesn't mean subpar. That means you've actually understood exactly what is needed and you're delivering. OK, so basically, down in the middle here, we've got the next to router's head over here is the architecture runway activities. And then they were putting on a whole series of works management and other types of activity around this. So they were still addressing the architecture requirements, delivering benefits to the organization, and still keeping in touch with. And if you look carefully, you'll see there where is it gone. Taking care of our assets. That was one of the major principles. There were five of them. Looking after our assets, our people, our money. And they have two others I can't remember, a fan. And those were basically the principles by which they structured their organization. So they looked at the strategy. They had about 2.7 million customers. So not a reasonable sized organization. And basically what they did is they turned around the way the IT worked from a very traditional reactive to a proactive approach. So understanding what the organization actually did from a business capability perspective, very simply, and then built the IT organization around the decisions that needed to be made in order to deliver quickly and effectively. Therein lies their basic use of IT for IT without actually knowing that it was called IT for IT, although they did go back and have a closer look at it. OK. One of the things that you might want to consider when you go down the accelerated route is maybe to re-look at the way you deliver projects. As in, why do we have projects? Project is you start here, you finish there, you probably overrun, you probably aren't up to whatever you define quality to be, and you're probably going to be over budget. The British Computer Society a few months ago completed a study. And they told us, although I don't think anyone here would disagree, that only 40% of projects in IT came in as they were expected. So basically, projects are there the right thing. Now again, do remember, this was a SAP-based organization. It wasn't one of these trendy kind of social media types of organization. And what they did is they did a way of projects. They had continuous work streams, which delivered incrementally. Actually very clever, yet very, very simple. They had some smart guys in there who were very good at agile. And they took those learnings and took them all the way back up. So again, just a few there. Projects could be suitable for one or things that can be delivered and then forgotten. Just get it done, that's it, and move on. But change is continuous. So why not organize the organization around the way our organization works in the industry it's in? Kind of makes sense, doesn't it? So the other thing that they did is that they moved towards work streams. And work streams themselves don't end like the organization. The organization doesn't start up, do a bit of ERP, and then stop with a bit of CRM, and then stop. It does all of these all the time. So basically they built the IT to deliver against that. So some really good stuff in terms of looking at how they could deliver on a dynamic strategy by creating the right thing. What business needed, making it available on an ongoing basis and then doing all of the good, detect the correct type activities. We still need that, but there's a very specific place for that. And of course, bring that thinking up into the early side of the whole strategy to delivery process. So there are some operating model challenges and drivers that we want to consider. Focus on the role of IT to deliver the services that actually make us stick out in our industry sector. Support a multi-sourced service economy. That's going to happen whether we like it or not. More and more is available throughout sourcing through cloud services. How many of us are building in cloud service broken as a capability within our IT division, our IT department, whatever you want to call it? We're going to need to do that if you're going to leverage services for the organization. And of course, we also want to be able to attract the right IT skills to deliver on the new IT. Again, as I said, this is something that is probably going to just continue to change. And of course, we have to build that change into our response with regards to how we deliver on our business objectives. So we can use IT for IT then to release a value earlier. How do we do that? We understand the S2P, the strategy to portfolio. Continue to address that. You don't do it once. Just keep doing it. Your competitors change. The organization changes. The environment changes. Regulation changes. Why don't we? Look at accelerated learning in IT. Basically make sure that we aren't using old fashioned techniques to address new technology problems. Doesn't make sense. Otherwise, it's a bit like a caveman looking at a jet engine. It's a thing of beauty, but it doesn't know what to do with it. And that's where we're going to end up with, or we might end up with. Look at IT for IT again in terms of your backlog of strategic priorities and changes that have to be delivered. And then look at how those are going to be fulfilled by your users, if you will, in old terms. Open up the capacity. Absorbed in wasteful activity. What do we mean by that? How much project activity is wasteful activity? Let's face it. 30% of projects are probably about filling out forms. And doing reports that no one reads, and that aren't actually useful. So again, we're putting cavemen onto a jet engine. Doesn't work. OK. And also then start looking at macro and microprioritization. That's the sharp end of how we can become a lot more agile in our thinking and in our delivery as well. So new operating model attributes. These aren't directly from IT for IT. But they do show things that are relevant in a new IT operating model that are highlighted, in fact, throughout the text of and the actual approach that IT for IT takes. Enhanced transparency. Agility and execution from the original thought to actually getting it out there. Speed is a new value proposition. We can't wait anymore. So let's get the right structures in place. We want to base our performance on business outcomes. So again, think about the front end of the process as well. So look at how we can bring accelerated thinking. And I've been careful in talking about accelerated thinking, not agile. Agile is a bunch of techniques down this end. We want to take learning from that and pull it all the way up into the strategy to portfolio type areas as well. So, and of course, then, stakeholder self-provisioning is enabled directly out of our fulfillment and some of the portals that IT for IT describes quite adequately, more than adequately, in fact. So we'd like to see all of these in the new operating model. Something that, A, we can address change with quickly and we can deliver what is actually required and can be measured. So standard IT from IT from the book. Basically, there's a lot there. And what we want to try and do is see how we can apply that to the accelerated delivery approach. But before we get there, we just take one more slide before the penultimate slide or so. So look at Kanban. Kanban is a way of looking at and managing pull through and the actual process, if you will. And there's some really good and really very simple things that we can address in our new or hopefully amended IT organization. Stop starting and start finishing as a general approach. Most of you have hopefully seen Kanban boards. I'm using Kanban because they're visual. You don't need many tools. You just need a big board, a couple of cards. And what you find is you get ownership of the activities by people on the work stream areas. They actually own that card. They pull it through. It's not hidden in a project, 600 line or 6,000 line project plan. So other things, pull, don't push. And again, the whole idea about pulling and not pushing is you do your piece of work and it's ready for someone else to pull through. So instead of throwing things over the wall and swamping people, basically what you do, and I've got mine done, then when you're looking at managing your own work in progress and you've got space, you then pull the next high priority piece of work across. Very simple. It's all got through the same process, but the way it runs is different. Prioritize continuously. Things change. And sometimes they change on an hourly, daily, weekly, monthly basis. You can get your exec to have a look at your portfolio of activities and investment, and they can prioritize. We have a situation where a client has said that any regulatory activity trumps anything else. So that's basically one of their rules. But they also come in and have a look at what needs to be done. And then lastly, govern actively. Just because you're going down the accelerated delivery route or using things like Kanban, doesn't mean to say you can't govern. You can govern just as well, if not better, because it's visual, it's there, it's available, and everyone can see what's going on. So how did we actually do this? We did it like that. There's a little bit more to it, he says. So understand where the organization was going. We then had to look at the organization in terms of not only understanding the strategy of the organization, but trying to rework that into what capabilities the organization needed. So basically, look at focusing on identifying the different capabilities. And then leveling those down to say level two. And then we started looking at what was necessary to deliver those capabilities, not projects, capabilities. And then we looked at, and I'll build this here, we looked at capabilities and the work streams going this way, vertically, but cross cutting teams that could pick things up. So you might have heard of terms like squads and guilds and all of this kind of stuff. If that's what your organization uses, or your client use, that's where it happens. But work streams, cross functional teams work perfectly. Okay, so a few things there just to remember. It's in small print, I can't read it, squads, et cetera. So look at various enablers. What are the basic things that those teams need to do? And prioritize them by those capabilities. And of course, if you look at those, it is a bit like lots of things just coming in. And this is what we want to manage with regards to the strategy to portfolio and then into the requirement to deploy areas in IT for IT. So just continuous change, continuous updates with cross cutting teams. Then of course, again, this is exactly how the GDN, the gas distribution network actually did this, they went down the Kanban route. Again, just using this over and above Microsoft project or whatever, not saying there's anything wrong with that by itself, but they said, no, we're not going to have it hiding in Excel spreadsheets. We're going to have it out there and available. And interestingly, we mentioned here that we're very interested in who is doing it. So we had the right people, but we're also interested in making sure, and I'll just move these on, that prioritization was done actively. We knew this was working when members of the board walked down the corridor, came into the IT area and started prioritizing things. Okay, we had a number of different boards. We went up to a portfolio board, et cetera. But when that happened, we knew, yes, they've got it. But enough to go looking in spreadsheets and stuff like that, they could actually see what was going on. They could see where their millions were going and then they could track that down. Okay, and of course, the whole thing is to pull work across. Of course, once it's ready, then you can start looking at making sure that you do follow up with all of the proper service management, service readiness, business readiness, et cetera. Of course, one of the other things with accelerated delivery is we start thinking about that early on as well. Okay, we also want to consider the actual team inception, et cetera, and the principles, et cetera, the policy management as you go through. So all of the standard good and best practice and governance is not lost. In fact, it becomes very visible. And in fact, it becomes quite a lot simpler. So very briefly, how did we see that where we used, in retrospect, quite a lot of the IT for IT. Top left-hand side, the strategy to portfolio was quite important. Equally so, the requirement to deploy. Get the stuff and build it. Build what the organization wants. Not what IT thinks it can do. And then of course, over the bottom right-hand side, the request to fulfill and detect the correctancy. But again, this is showing that a lot of the major changes in the IT side of things were the top left. Strategy to portfolio and the requirement to deploy. And those are quite often the things that are difficult for us to get a handle on in the IT side of things. So a few parting comments then and observations. Make sure your vision is clear or that you understand the organization's vision. Even if you don't have a strategy or it's not yet available to you. Some organizations we work with have their strategy plastered all over the walls right into the toilets. This is what we do in this kind of companies. Guys are really proud of it. Other organizations, you just can't see what they're doing. And it's kind of you've got to know someone who knows someone that can tell you exactly where the organization's going. So again, make sure that we know where things are heading. Don't confuse roadmap with strategy. Roadmap is a consequence of planning out our strategy and getting stuff done. Start small. Most problems arise from people, not technology. I think someone else mentioned that earlier. I think Craig mentioned that as well. The technology will quite often have been tested of thousands and thousands of hours. But it's getting people to work together in different ways is the challenge. IDVRIGHT isn't the entire solution, but it's a jolly good base for starting us on that journey. And just getting to, even if you get to one point, understanding the four value streams in terms of how an IT organization runs itself as a business, you can be way ahead of from the old IT. Of course, we can't ever forget our architecture practice. Invest wisely is all I'm gonna say. That could degrade into a religious debate. But we'll leave that for the time being. Reconsider projects, move towards work streams for continuous and incremental delivery. That's got to be the case. And it doesn't break architecture if you go down the runway route. Reconsider, I've just said that, integrate rather than implement. Implement feels a bit like starting from scratch. Most organizations have got some good stuff. Don't waste it, just build on it. Use the standards that are there. And then finally, agile is a right hand side technique. So basically it's over here. But there's a lot of learning that we can take out of agile, and I mean agile generally speaking, all the way up through to understanding the strategy all the way back down. So it is a left hand side to right hand side approach when we're looking at accelerated delivery. Especially when we introduce a lot of the concepts that all.