Yes, maybe not so much vary compared to the Agile community, but very different than a lot of the people that I run into that are involved in Agile at the conference here today. But my background starts in banking so it’s a heavy finance background, and after a few years at ING I became involved in executive level management in an oil company and after that in a financial consulting. I did some investment banking, but largely what I did were executive roles, interim management with restructuring businesses, as a chief restructuring officer, CEO, CFO, those types of roles.
That’s interesting; it’s a very welcoming crowd thankfully, because certainly I sometimes feel like the odd duck, or the odd man out in the conversations.
4. And you are (editor note, jokingly)!
I always have to kind of – on the front end explain to people that I have a very low technical IQ. I can’t bring a lot to the party on there, but I do have a pretty deep background when it comes to project management, portfolio management, those kind of things. So to your question, I got involved with Agile back about five years ago when my brother and I purchased Solutions IQ. And at that time Solutions IQ had a presence in the Agile consultancy. We are a small consultancy and we were doing some of our development, our outsourced development, in the Agile manner. And over the course of time we became more and more intrigued and based on the success we were having with those projects, we moved to the mode where that became our dominant offering. And through that period of time, about three and a half years ago, it really peaked my curiosity, just given the fact that where my history especially in the restructuring side I could see a lot of failed IT projects, is that we had our share of challenges with the waterfall projects, but we just generally had very good track record of success with Agile. So that’s what kind of peaked my curiosity and I stared to dig in from a financial prospective, what were the differences and how do these things kind of compare to what traditional standards have been
I think that actually what today is traditionally used for business cases, probably hasn’t changed that much, and I am going to kind of push Agile to the side. But from an executive sponsoring of a project it dates back many many years and it was for good sound reasons. And if we think about, let’s go ahead and pick the sixties or the seventies, we can take a period of time where from our prospective there wasn’t a lot of rapid change going on. Now maybe compared to the 1930s or the 1960s there was rapid change but what was important from an executive level is if I am looking to sponsor a project, what’s my likelihood of pay back from the project? And 1960s, 1970s my horizon was actually fairly long, which means that if I was going to go ahead and move forward on making that investment, I could expect to harvest that investment for a number of years.
So what was established, and established for a good reason at the time, was a methodology that said ok if I know that I could get a long term return what are my risks in the project? So when I have that long-term certainty my risks really become on the front-end. And on the front-end what I do is I start to develop a project where I know I’m not going to go over budget, don’t want to go over budget, and I really have to control the costs, control that down. The other thing if I’m going to build, I am going to build once and I am going to build big. I am going to get all goodies I want in there. So my requirements are going to be very very very deep, so by nature what I’m doing is I’m developing something big that I can harvest for a long period of time - instead of doing many projects. And it’s going to be something where I am going to get as fine a detail on requirements as I can because of the certainty of the time I could actually go out and bid this and have success executing it and then realizing that value.
Things have changed from where we stand today and the reason is that we’ve got Moore’s Law in technology is changing and increasing, which is great. It’s great from our perspective because as consumers because every time we into the store there are more goodies and kind of look at different gadgets and things. But what’s troubling from a company that’s actually bringing products to market is - what’s my product life cycle now? Where back at 1965, or 1975, or 1988, I might have some reasonable certainty that I’m going to be able to harvest for five, ten or fifteen years.
Now I’ve got things that are changing so rapidly that if I go to market based on what I see today, in all likelihood six months from now, twelve months from now, am I going to have a product that if it reaches my vision of today that’s going to meet the market. So that’s where you take the traditional standards, which is build it big and build it with a lot of requirements, and then you try to kind of squeeze it into all this uncertainty with where the market is going and then there’s this misconnect.
Yes, and so now what you do, if you take that same approach and you want to build big and get all the features, well one is, you really don’t know what those features are or what’s necessary. So it becomes somewhat guess work. And when you had the confidence of that business case in the 1960s, you had reasonable assurance that your assumptions will be pretty much on mark and the market wasn’t going to change that much. And right now the assumptions are so upside down, that when people build the business case, there’s so much inherit uncertainty, that you can’t with any degree of confidence kind of put it together. So you need to get it to market as soon as you can, as quickly as you can. And you need to be doing it in a fashion so you are not building big but you are building small. And again it starts to feel like Agile a little bit but on an iterative bases that you can inspect what’s going on, how the market feels, what’s going on with your competition, and be able to modify and go forward. So you’ve got a market that is very dynamic in changing you need to have a process that’s very dynamic in changing.
I think one of the big problems is that we’re, aside from kind of the traditional business case model that we are stuck in and this is what we have all been trained in business school and everything else, is we’re also stuck in this thing called the annual budget cycle. If you think about kind of historically IT versus the business, and the fact that they don’t cooperate a little bit better, maybe it’s due to the fact that there hasn’t been this tremendous success from both sides prospective, working together on projects. So I think the dynamic there is not necessarily a good dynamic, and when things like Agile emerge and there is some success, what we’ve seen a lot of times is that at the executive level there is kind of an abdication. Which is, if Agile is going to make it work, make it work but don’t bother us with that just go make it work. And that’s fine because you can get value in doing Agile at that level but when you really untap the value is when it seeps up into the executive level. And you can unlock the potential from how you do in your project management; how you are actually doing in your business cases, and how you do your overall portfolio management. You kind of take something like the annual budget cycle and maybe break that apart, and again get into a more nimble approach.
We’re see more and more that there is kind of the “expedited” process that certain companies will do to bring this to market, but that may crash and burn a number of projects that are in the old system in kind of working their way through the old system. But you are absolutely right – you hit the nail on the head. And that is… when you’ve got that vision, whether it comes from market or wherever comes, that product vision, the period of time when you walk it into the annual budget cycle to actually delivery and in particular if you are not doing iterative development, is you may be looking at as much as two years out and frankly it becomes worse.
Yes, so there are a couple of things. What we’ve done is we’ve… You know, I don’t know if there are any original ideas out there. But, it’s those that can harness a number of them and can put it together. Real options were developed in the 1970s. And what it is, it’s kind of an incremental approach to capital investment, is a rough way of putting it. The way that I would state it, that it was probably more envisioned though was not so much in line with kind of an Agile project management, but more so if you had an event in the future, for example, if there was going to be a regulation change, and you needed to move forward on a project, and you are anticipating maybe a law the Congress is going to pass, it could impact whether that is going to be a thumbs up or a thumbs down. And then you would value whether you would want to go forward or not.
So there was an option, there was a cost of the option, you know to kind of move forward. But it was still kind of baked into the traditional business value of doing a Net Present Value, you know - kind of on the front-end. And what we’ve done with our approach in talking to our clients, is we take real options and we break it into kind of three different areas. The first is on the discovery and what I mean by that is there are a number of great ideas that we have that come from the market place, come from our customers, come internally, and the ability to kind of deem those projects on the front-end doesn’t make a lot of practical sense. So the discovery phase is really just identifying those projects that seem to have strategic significance, or tactical significance, but really haven’t been fleshed out to the point where they are tangible enough. And then, what we would say is that from an option basis is that you make the incremental investments in that discovery phase, until you get to the point where you’ve got enough definition where it makes sense or it doesn’t make sense… or it’s modified to a point where it makes sense.
Next would be R&D. Now it starts to feel a little bit more like a project where you’ve got something tangible that you can hand over to your R&D group, that’s going to flesh it out to see “Ok, if we were going to build something like this what would the size be, how could we do it, how does it integrate with our existing systems?” and input those pieces together.
The R&D process gets you another level of discovery, and again, on an iterative basis you can flush it out of that process at anytime it doesn’t make sense or accelerate it to the extent that it looks like it has good merit. At a certain point you actually need to say “Ok, we have enough information now, enough of our variables have become constants, and we can turn this into a business case”. And it meets whatever internal threshold we have from a return perspective. Big caveat on this though, instead of traditionally how we have done things - which is once the business has made the decision and they push that project over to the PMO and just say “Spend the money. Deliver the reqs and spend the money”, is we back away from that and say “You know what? We’ve approved the project – it makes sense - but we want to test it every iteration. And we are going to re-ante up that business case and we’re going to confirm that the assumptions that we’ve put in place are actually panning out, market conditions haven’t changed, and we are going to recalibrate the IRR ”. So what we can do is: one, is kind of see where we stand and see how the project’s tracking; and number two, we can at any time make decisions and say let’s shut this down, let’s accelerate our time to market, shut down at that point in time, let’s add additional resources, because we like where this is going. And obviously always modifying the backlog.
11. So you mentioned you were looking at the internal rate of return literally in a bi-weekly basis.
Oh, yes I mean I think practically where you start out with companies that are on an annual budget cycle, is that you probably want to break that in two and then you want to break it in four, and I think that practically if you can get to a monthly cycle, is the best way to go.
Now if you think about it in the context not of a single project but in the context of a number of projects, portfolio management. And one of the problems I always had with portfolio managers is somebody takes a job at the beginning of the year, and they are inheriting a number of legacy projects, which he doesn’t have ownership for, because the money has already been allocated, that’s going to be somebody else’s failure. At the same time to the extend that new projects should come on board from the prior year, again there is not a lot of sponsorship there, that’s something that they’ve inherited. And the fact that there is so much turnover and most people aren’t in their position for more than about two years, you’ve got this constant state of nobody is accepting responsibility. So what is the job of portfolio management other than to confirm that all the money has been allocated and spent? So what we try to encourage our clients to do, is if you can get to a monthly… let’s start with a quarterly iteration. On a quarterly basis is we actively take a look at what’s going on with the portfolio. We’ve got a very good idea as to how the projects are moving along, and we’ve got a sense of what their relative value is amongst the group.
Also we have a sense when all of a sudden something does get expedited – a new competitor comes to the market with something we haven’t had. And to be able to take that in context and now make real decisions across the entire portfolio and say we have a new project coming in, this project isn’t panning out the way we want it to, the market has changed and we actively manage and you can shuffle resources around those projects so you are optimizing.
Get engaged in the decision. Because if you take a look, we talked about that friction between business and IT and I very much believe it goes back to these failed IT projects. You asked me for ten million dollars. I gave you ten million dollars and the project cost me seventeen million dollars and it never delivered as expected. Bad IT! Bad IT!
14. Well now you know why people in the Agile community don’t like you so much right now.
That’s exactly right.
ou absolutely should because it’s not fire IT. That’s not the solution. What it is… When as an executive you are saying: “Ok, we’ve agreed to ten million dollars and now what I am going to do is have a lot of sleepless nights for the next twelve months and hope this thing is delivered” - that’s not really active management. That’s an abdication of my responsibilities as an executive. What I want to do is, I want to go in and on a monthly basis see how things are coming along, and see that they’re delivered. I don’t want to check my progress by how much of my budget has been burnt, that doesn’t make a lot of sense.
Yeah, this is the - and again we talk about some of the challenges. From an executive level the biggest challenge that I always tell my clients is cultural change. And are you willing to embrace failure? Because if you are not willing to embrace failure, you can’t go down this road. Because what you are talking about doing at every level of the organization, is you want people raise their hand and say this has a problem, this won’t work, we are going down the wrong path. And you want them to be able to do it obviously in an articulate way that has some top of a basis. But you want them to do that because you want them to tell you to stop doing stupid stuff.
17. Don’t do stupid things on purpose.
Don’t do stupid things on purpose is another way of putting that. And that leads to really a relationship change, from where management was with kind of the knowledge worker in the past versus where they are today. And I would characterize it in the past, back in those great days when you had long expectations on return. Let’s say that I was in the oil service business right. Or I wanted to get into the oil service business and say open a division in the oil service business. So what I want to do is I want to be the best there is. So I am going to go out and get the best geologist. They’re going to tell me how I can find oil. And because I got the best geologist and they are going to tell me I’m going to actually put a process together that, maybe not the best geologist but kind of mid-level geologist can execute that so that’s going to give me because I took this best practices policy, or process together, and I got workman like people that can execute and they can point to the spots on the ground where we should drill. Then I go and get the best petroleum engineers that there are, drill engineers, they are going to tell me the best process for trying to find it once we drill in the ground. Then I’m going to build that into a process and then we get a bunch of workman like process engineers and they are going to execute. And that’s knowledge that I can capture, I can actually own it for myself, and I can move forward, and that worked well in the old days. But the way things have changed, because everything is so emergent, and in particular when we are talking about software, is we no longer have the ability to just take the knowledge and pull it up, because we don’t know what elements of knowledge we need. It’s not just find the spots, where to drill.
18. Is this quoting Donald Rumsfeld’s “Unknown Unknowns” or something like that?
I would never be accused of quoting Donald Rumsfeld. Not purposefully. But what’s interesting is that now we have… what we need from our smart people, is we need them to tell us what’s important. We need them to tell us what’s emerging. So the difference would be is if I might pull somebody who is a great nature expert and say sit down in a room and put all the things you know down on a PC for the next month. And I’ll capture all that knowledge and I can use it. Well, what knowledge do you need? When you are in the midst of being lost in the desert, that’s one element of knowledge. When you’re shooting through rapids that’s another element of knowledge. Maybe you can master both but it’s the specific circumstances that you need to apply at the time you need it. All the rest of it doesn’t make a difference. So when we can actually establish a relationship with our knowledge people where they have the freedom and flexibility to identify what the needs are and they can tell us when it’s important, that’s extremely important. And one of the push backs that I get from executives is… well, you don’t know what you are talking about doing, it’s recess time. Let everybody do what they want to do. And I kind of laugh at it because I frankly have never seen a better controlled system from an executive management prospective, than a two week release where you’ve got actually business defined release at the end of the two weeks.
So from a boxed in control is you got people that are stepping up they are saying “We’re going to take this and we are going to execute it oh and by the way at the end of the two weeks, we are going to show that we did it based on your definition of making sure that it’s done”.
And we are not asking the development to come up with words of value, that’s going to be the job of the business or the customer depending on how it works out. We’re also not asking in a sliding scale of projects back and forth for developers from IT to come up with necessarily explain what needs to be done, that has to be the job of the business. The fact that this has all been kicked over the fence historically and that we haven’t had success, now is the time to kind of wake up and do things. And I think we really are at a point… it depends upon what area in the overall economy you are playing in, but if you are in a fast field where things are changing, it’s not just a nice to have anymore, it’s absolutely essential for the survival of businesses that you are enough in tune with your own organization, and you can take in what’s going on with your customers, with the market environment and with the competition and be able to in real time turn that into something deliverable.