Using RO to Design IT Projects

Speaker A My name is Alf Rock. I'm part of IBM Global Services. The practice I'm in is the transformation and optimization practice. We've had a and we've just evolved into the transformational aspect of it. We're fondly referred to ourselves as the technology knuckle dragging group of people that got to the point of failure. We would fail into Next systems and we would put in the technology. And the technology was good. Still not a happy ending. We figured out the processes. Processes are good, the people look normal. But we started to recognize that we just didn't understand what peoples were. We were meeting Albert Einstein's definition of insanity, which is to repeat and not learn. Right? So the other Einstein's quotation that we were really following is you can't solve the problems at the same level of thinking that you created those problems. So we needed to fail ourselves to the boundary of breakdown, and then we would break through to other dimensions. And the dimension we broke through was, okay, we understand technology, we understand processes. What is peoples? And like, good IBM as we started off with architectural building blocks, what is the architectural building block of what peoples are? So if you examine it as a resident alien coming to this planet to try to understand what peoples are, you start to try to understand the levels in architecture. And of course, we're technologists. So there's a lot of resistance to some of the notions of Ro and some OD things. But technologists don't seem to have a problem because they're more architecturally inclined to looking at levels and layers in terms of OSI technology models. And they're also, if you just described Iro, it's like the CPU running in someone's head and they're currently running with a three eight six or a four eight six or a pentium. It's an easy metaphor for a technologist to understand. And they're going to get their upgrade. They just haven't had their upgrade yet. They still need to mature into upgrade. Those notions are not as alien to technologists as they are repulsive to other systems of thinking. And I mean repulsive in terms of they reject it anyway. As a technology group, we now understand that when we go into an environment, we deal with that three legged stool aspects of things. There's the technology and there's the processes and there's the people side of it. And we need to understand that if you take technology and you throw it at a sociocultural structure that is not congruent to that technology, it's just going to slide off. And that's the reiterative failures that we've been talked about. So throughout the process, the last four or five years, we've been mapping what the next appropriate step is from where the habitat is, where the individual is, where the collective is, and what the construct of the next appropriate step to that ladder? Stairway to heaven, if you want to call it, to get to that place. The thing is we're closeted. We're undisclosed to a very large extent because we don't come in as organizational development consultants and organizational design consultants, we're just those technologists. But we're also excellent customers of the people stream. And my colleague here, Valerie Hickey, is from the IBM Global Services. Global Business services and learning and knowledge and OD side of this job. So I get to be her client and we start to construct things in terms of an integrated view of technology where the solution is brought about, the process stream where the service is constructed and the people stream where the experience is constructed. For the end user, for the client and for the practitioners immersed in the delivery of the solution and the service. So that's kind of our holistic view of it. But we don't have the tools to actually go and probe people or ping them. We have our own ways of pinging people but we don't have it in terms of empirical investigation and so we play the pin and tell on the donkey game. So we would come into an engagement and say we are a systems informed practice and we have something that we coined the three four three model which the first three represents the three systems of what happens around here. Now I don't know whether this is a fair representation of Ro but we basically would ask somebody so where are you on the map? Because we kind of view that the lower system that actually does the doing part of things, where the real power is in an ADIZ model is where the execution of action happens, is down at the bottom layer. And that layer tends to be closed in its means and its ends in the sense that you can't having people design how you do the doing part of it because it has to be a consistent, repeatable, manageable, measurable process so that process better be designed. Technologists are infamous for throwing the solution over the wall and expecting some magical miracle process which invariably does happen. That the system self reorganizes to actually figure it out. But what we end up having is we end up having level three people in level one positions doing level three work which should have been done earlier on. So when you actually do the numbers you're way overpaying for your technology. But that's okay from a technology point of view because we're operating on a purposeful manner and a purposeful manner is service provider centric. We're there to maintain our agency. So at the higher level that stratum is supposed to be producing decisions and that's not closed, that's not a homeostatic system, it's a purposeful system. So this is the layer where strategy is supposed to be figured out. This is the layer by which we decide what ends we're supposed to be achieving and we're supposed to construct the means by which we do that at a lower level. So these guys are supposed to be producing decisions. And the presentation that we just went on is one of the problems is that if you put level two three people and level three four jobs up here, they're not coming up with the goods. And one of the things is, when they do come up with the goods, they come up with the goods visa vis their decision and authorization to spend money in a time span that's so late that these guys never actually get a chance to do or to plan. So what we end up doing is load, and we end up load. This is supposed to be load, aim, fire. And what we end up doing is load, miss, load, fire, load, fire. We never take good aim. This part of the system, which is the goal seeking system, which is the three four level, is supposed to reconcile the serialized planning and integrating the different aspects of it. So we play Pin the donkey. Where are you on the map? Oh, I live here, or I live here, or I live there, or some people would draw, this is kind of my space, this is the space I live. So people self disclose. And in the process of that self disclosure, people are informed about what we refer to as a full spectrum engagement. So the notion of a requisite organization, we use the term a full spectrum engagement, where the decisional level, the planning level, and the doing level are all aligned. And a full spectrum means that the decisional level operates with the percolated complexity of what's happening down here. And the decisions are then given to the middle layer, which then translates that into plans and action. That's the full spectrum engagement. And Ro fits beautifully into that. So we then take the four dimension of our model, which is the so we've done the first three, there's three systems, the four domains, which is to plan and organize, acquire and implement, deliver, support, monitor, evaluate. We made it real easy. We took all our IBM terminology, threw it out and adopted an open standard COBIT, which is the compliance of objects in it project, which is an auditing and oversight governance model. So we've used that terminology and there are four domains. And what we've designed because we as a team go in, have absolutely no option of organizing because it's easy for it. We failed because you guys are just we fail because of you. So what now we have is an engagement model that actually informs from an Ro perspective, where things can be reconciled. Where we've got somebody who's a level three thinker or a level two thinker trying to struggle, God bless them, with a level three job. So how do we do that? So how we do that is we start to build social technologies into our engagement model. In other words, we move from an egocentric culture of monarchy and management by decree to a social structure of parliamentarianism, where we have a lower house and an upper house where the plans are voted in or vetoed out. And before they go into operations, this is the run state. The QA One is a highly incentive social technology because our rule is we don't release funds until we've done this. How many people understand hockey in this room? So to explain this to Canadians, it's really easy. It's actually based on a hockey rink. This is the blue line and this is a blue line. Okay? If you're playing hockey and you whack the puck this side of the blue line up the thing. As soon as you whack the puck, the hand goes up and that's an icing call. You can't do that. You must pass the puck into the middle zone. If you're on this blue line and you step over the line before the puck, that's an off site. That's a straight rule. So we're moving towards a purposeful, rule based culture where project managers don't turn up, that have to sail a ship with a manifest, a ship's leaking. You're underresourced and all you can do is start spewing up risk mitigation strategies. You're in trouble before you've even started. You're never going to really make it because it projects deliver. Trivial Pursuit question what do I treat projects deliver more than anything else? Excuses. So what we do is we have these social technologies here that reconcile the required level of parallelism to execute. So here's the parallelism and this is another view of that. So here's the first part. You start with the architectural view. You go through to QA One. You implement, you test, you create an operational plan which is the organizational structure and the work and core flow process for this organization to run with the solution. And we're at the brink now where we're going to be coming out of the closet and going we're going to be using requisite terms to describe this and describe all of this. Right now we're still using PowerPoint eye candy. But eventually when you look at what we're doing in terms of designing the work, this is the work and this is the final three because we've now got the lower order thing, which is technology, then that delivers the solution. A higher order thing which is the service which is done by the process stream. And of course the most difficult thing in the game because who understands people is the people stream deliver that. And what we have is a way that these things are integrated at a QA One level and a QA two. And as it moves forward. And what we have is Gating one, Gating two, gate three is actually the gating process for the procurement mechanism. Wouldn't it be a good idea if we had so and so? Let's kind of do a swag on it order of magnitude and then we get to the point where a business case is put together and statements of work are gathered from vendors and that's when we undertake the project. Traditionally the problem is that the people coming into the organization usually give you a statement of work that says this is what we're going to do for you, these are our responsibilities, these are your responsibilities and these are the assumptions. Well, your responsibility and the assumptions, as you know, never very good at reading, right? Exactly. What you do is you take those assumptions and put them straight into the risk log because they never really happen. So we're shooting ourselves off in the foot, right off the bat. So what we've done that is within those gating processes we now have the QA one process that makes sure that we've provisioned for all of these other things to be done. So in lieu of the fact that sometimes organizations aren't requisite in some respects and I don't know if this is really I'd be interested how people feel about that, we are making sure that we've established a social technology. That either collectively, people responsible for multiple serial things can reconcile that through a meeting or that a level four thinker comes up and goes, I'm vetoing this because I don't see the level of work that is required before we release millions of dollars into this project. And that's what we're really good at. We can release that. But thankfully the world has kind of given up on that. So that's where we're at. And then we kind of dig deeper and deeper in terms of the internal methodologies and now I kind of dig deeper into that. But one of the most important things that we have and what I included in our abstract is the importance of something that we do in terms of our execution within the process stream. And that's how we build out service request matrix. And while we actually implement a solution, let's say I'm going to drop this technology solution on your desk, on your habitat and you are the users of that. The users of this system is now being put into production. We have a team of people here that are now going to be responsible to provide day to day service, help desk service, incident management services. Please. Can I have this? Usually we are challenged at reconciling those things because all of my effort is going to getting the technology to you and we haven't actually delivered the operational model. We're now at the brink that we have the internal methodologies of delivering the operational model by capturing in the artifacts declarative and cumulative perspectives as we go through the lifecycle into the model. And then because that's really great insight, but people that usually see the problem have access to sensing the problem, aren't the people who are actually in a position to process the solution. So what we've done is we've created artifacts that captures the level one and level two observations. Then we classify and categorize those observations and through various people stream workshops. We then synthesize the thinking into creating workflow knowledge items through the people stream. And then we then map that organizational workflow into a tool where the support people, you call them up and go can you give me ABC service? And we've designed it in a way that the support person doesn't actually need the training because embedded in the tool are your knowledge item that will flick up on adjusting time knowledge base that goes, this is how to provide, this is the knowledge item to service this request. Should that knowledge item not be sufficient enough to do that or should there be a lack of that knowledge item, or if the knowledge item says just pass it on, the service first level support will pass it on with the tool. And embedded in the tool is the knowledge in the tool that I'm now going to distribute that work request based on a skills base. So right now I've got four people that can service that request. As the request moves on, we might need to train somebody else, put them on that work stream and it distributes it and those people then services. So we've got that embedded in the methodologies and we've got the tools and technologies to do that. Meanwhile, as that's happening from a people stream, we proceed where the people stream goes. Our impact assessment has told us that these people don't even know how to use a PC. Therefore we need some orientation program and a whole bunch of interventions required. From an organizational development point of view, all of that drama is played out and then comes to fruition. After we've implemented, we've piloted we're a go go. We have a QA Two process which all the stakeholders turn up, not just the sponsor, but all the stakeholders and all the people who have accountability to run the system, to support the system, third level vendors, whatever it is. And effectively everybody gets a power of veto that goes. This is an outstanding issue. And what we do in a QA Two ritual, which we've used, the wedding metaphor, it's not so much getting a bride, guys getting rid of a son or whatever. Different people see it in different ways. The whole wedding metaphor is such that we have some basic rules. One, it's a yes, two, it's a yes with a qualified variance. So it's like you got a yes, but we got these three things you got to clean up and then we kind of put some accountability to that. Or we have a no with variances and then there's a no with extreme prejudice but we haven't gotten so that's kind of where we're at. And because we're ro informed, we recognize that certain qualities in the work product needs to emerge in organizations that might not have the requisite structure. So what we've built into it are some safeguards and checks and balances in the model that we're doing. And now we're at the stage where we want to start to express the model of the organization that does that in requisite language. So we'll have the structure built out, we'll have the tiers built out, we'll have the Tars built out, because this organism needs to talk to a formal structure of IBM and a formal structure of the client and a formal structure of external partners and suppliers and vendors. So that's kind of where we're at right now. Sam.