Sie sind auf Seite 1von 20

Focus IT Roundtable:

How to Recognize and Prevent IT Project Failures

Focus Research, Inc Moderator: Michael Krigsman April 25, 2011 1 pm PT

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

About the Roundtable: Focus Expert Roundtables are 45 minute teleconferences where 3-5 members of the Focus Expert Network talk about hot topics on a particular category each week. Failed IT projects cost the economy billions of dollars every year, damage many public and private organizations, and hurt the careers of those involved. On April 25, 2011 top experts explored why IT failures are so common and what you can do to prevent them. Michael Krigsman: Lets begin. Welcome to this Focus IT Roundtable called How to Recognize and Prevent IT Project Failure. Im Michael Krigsman, CEO of Asuret, which provides change-related consultant services on business transformation projects. I also wrote a popular blog for ZDNet called IT Project Failures. This roundtable is brought to you on Focus.com, where Im a Focus Expert Advisor. Focus brings together a large community of experts and business professionals to exchange information and share knowledge. And if you havent participated in the site, I strongly suggest that you do. Focus will be posting a recording of todays discussion within the next 24 hours, and a transcript will be up within the next week. To access the archive, use the keyword projectmanagement on Focus.com. You can also interact with me and the other experts participating in this roundtable over at Focus. If youre on Twitter, use the hashtag #focusRT. And well be monitoring the Twitter stream as we go. Today Im joined by two top experts on IT failures. Steven Romero is an IT governance evangelist at CA Technologies, and he literally travels around the world giving presentations on this topic. He speaks with practitioners and enterprise customers every day of the week, and you can find him on Twitter at ITGEvangelist for IT Governance Evangelist. Im also joined by Todd Williams, who is one of the top project turnaround specialists in the world. His new book is titled Rescue the Problem Project. And Todd works with enterprise customers as well, and also travels the country giving talks on this topic very frequently. And hes on Twitter at BackfromRed, as in taking back from red projects. Its an honor to be here with both of these folks. So lets dive right in. Steve, lets begin with you. Despite all of our metrics and project management tools and everything else, statistics tell us that a large percentage of projects are late, over budget, or dont deliver expected results.

2011 Focus Research

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Making matters even worse, I wrote about a study showing 75 percent of the respondents anticipate that their project is going to fail. So Steve, whats going on here? Why is his happening? Whats shaking? Steven Romero: Hi Michael. Good afternoon. So yeah. Its a question. And Im a broken record, when it comes to answering this question. So its great that were gonna have Todd here as well, to get into some of the execution-level problems that Im sure many organizations are experiencing. And after speaking to many folks in companies out there, I have found that a major contributor to these project failures is a lack of sound investment decision making about the products and programs that an enterprise undertakes. So poor project and portfolio management practices thats probably the thing that I cite more often than any. Organizations are not deliberate enough or conscious enough of how they choose products and programs. And these things get thrown over to the fence to the people that are supposed to execute these things. And, in many cases, they dont have enough time. They dont have enough resources. They dont have enough money. And without good investment decision making, those deficiencies or inadequacies or obstacles dont get uncovered. And, frankly, its left to the heroics of many people in the organization to actually get 'em done. And the other one I think its one that Ive seen you write quite a bit about and thats the inattention to business process change that should coincide, happen in parallel, or actually happen as a function of the project thats introducing the new system or application. Ive seen that cause many failures as well. Michael Krigsman: So Todd, business investments is that the problem here, that companies arent investing right? Or is it something else going on? What do you think? And please speak up, both of you guys you need to speak up just a bit more. Okay? Okay. So I dont really think its an investment issue necessarily. Its potentially that people are going somewhat after the shiny ball. They see something. They see Geez, I want that. But theyre unable to take that concept of what they want, and translate that off to what they actually need. So too many times, a project is started, and it looks like its going to address some sort of business need. But its off-track from the beginning. That gets right back to what Steve just said how these things get started and thrown over the wall. That whole throw over the wall issue is a huge problem.
2011 Focus Research 3

Todd Williams:

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

So whenever Im looking at an organization and trying to figure out how to make the situation better, so that they start projects that are more on target with what theyre trying to do, one of them is to break down that wall to get that throw over the wall out of the way, to get the people who are actually doing the true project inception thats taking place months, maybe even years, before the project actually gets started They have this idea to make sure that idea is well vetted, well understood, and that they are drilling down to what their real core issue is that theyre trying to solve and address, instead of implementing the next shiny ball. Michael Krigsman: Guys, I was gonna try to wait to put you on the spot til we got into this a little bit more. But now Im totally confused. Because what Ive heard so far is its an investment decision problem. And yet its also, at the same time, not an investment decision problem. And not only that, if we want to run a successful project, we need to start thinking about it months or years in the past, before we begin. So whats going on? Let me try this. What is an IT failure? Or whats an IT success? Steve? How do you even define that? Steven Romero: So how to define it? Thats interesting. Because I think a lot of it has to do with maybe semantics. Because I have a feeling that Todd and I are actually agreeing with one another. Because when I say its an investment problem, Im talking about the processes by which investment decisions are made. And a huge factor of that a huge aspect of that is making sure that the investment is capable of producing known business value thats theres a good understanding of that. And I think Todd was really touching on that quite a bit. But when I talk about failure in general, what constitutes a failure to me is if a project takes longer than we said it was gonna take, then its failed. If it costs more than we said it was gonna cost, then its a failure. And if it doesnt deliver business value the business value that was required when the first idea for the project or program came up if it doesnt realize that business value, then its a failure. Now thats not to say that it should have never been undertaken. It just means that the processes that were in place to come up with the idea, and to form the project, and to undertake the project didnt meet the objectives of how long we said it was gonna take, how much it was gonna cost, and what we were gonna leave behind when we were finished.
2011 Focus Research 4

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Michael Krigsman:

Well, okay. But then Todd, if I define a project with a set budget and timeframe and set of deliverables and so forth, and once we get into the project, it turns out that for I don't know 15 percent more budget or 20 percent more time, we can actually get a lot more accomplished, and its all good stuff, according to Steves definition, the project failed. So how do you handle that? Well, I would take Steves three points that he put out, and I would flip them the other direction. And I would say first and foremost, you have to deliver value. If you deliver to time, scope, budget, youre not guaranteeing value; youre guaranteeing a set of metrics. Value is not necessarily measurable is part of the problem. Hold on. Wait. Wait. Im gonna just interrupt you here. Lets go on to the other two pieces. Sure. So what youre saying is if a project goes over budget, thats okay? Im not saying that its okay; Im saying that its not a failure. And theres a difference between the two. These are not ones and zeroes for a project is a success, or a projects a failure. Uh-huh. If it goes over budget, and yet it provides more value, and gives value to the customer and the supplier, and they agree that values there nobodys complaining. Its not a failure. Okay. I think whats important though is that you dont come up the people that are actually doing the project dont come to sponsors and business users and the people that are waiting for the product of the project they dont come up after the fact and say, Oh by the way, we spent this much more money, and delivered this much more value. As long as that extra money thats being spent, or the extra time thats being taken is taken back to the decision makers who first set this investment this project or program on its path. As long as they go back to them and say, Hey, weve got the opportunity to actually realize more value if we invest more money, or if we invest more time, or if we change the scope, or whatever the case may be just as long somebody is actively looking at that change and determining that, yes, its a good idea for the enterprise, and then sanctioning it.

Todd Williams:

Michael Krigsman: Todd Williams: Michael Krigsman: Todd Williams:

Michael Krigsman: Todd Williams:

Michael Krigsman: Steven Romero:

2011 Focus Research

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

And at that point, though, the project is reset. And now we have a new budget, and now we have a new schedule, and now we have revised expectations as to the value. And those become the revised measure to determine whether or not it eventually failed. Todd Williams: Steven Romero: Michael Krigsman: Yeah. Change management. Exactly. So what Im hearing from both of you then is that the key point is that there is explicit acknowledgement, explicit recognition of what the expectations are, and what you hope to get out of it, and how long its supposed to take, relative to those results. And if you want to change it, and everybodys on the same page, and the key stakeholders agree, then, in fact, all is fine. Steven Romero: Todd Williams: Oh. I would say so. Absolutely. Yeah. Now the thing Id add to what Steve said is that you may be going down the road of building a project, and just not saying, Hey, I can get more value if I do this. You may see that Wait a minute. The values not there. What am I gonna do? This is, as far as Im concerned, one of the huge attributes of Agile when you put Agile in is you have these checkpoints on a very regular basis. Am I getting value? Am I getting value? And you can make a kill quick decision to shut the project down, or be able to move the project in some direction. You dont need Agile to do that. Its a good facilitator of it. You can be in the middle of a standard waterfall project and say, Im not gonna get the value. If you put together a plan that says, Okay. But if I move this around and move this around, then it can happen thats not done by the project manager. Thats not done just by the sponsor. Its done by the entire set of stakeholders, as a group. They all have to agree. Michael Krigsman: It sounds very painful, quite frankly what you just described. I mean Im just thinking of a group of stakeholders sitting around with a project, and money is being burned. And it just sounds painful to me. It probably is. But given the extent of the failure that youre describing and if you have 75 percent of the people that youre surveying saying, Were on the road to more failures, then maybe establishing that governance and that oversight and those people that become the caretakers of whether or not a project or program is on the right path,
6

Steven Romero:

2011 Focus Research

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

and continues to show promise in delivering that value it may be worth the pain. And thats something that I bring up to most organizations. Determine what their threshold is for the failures. How many failures are they actually experiencing? Because a lot of the pain that youre describing at least how you characterize is as pain we want to make sure that its worthwhile. If an organization has just a few projects failing, and theyre able to do things quickly, and theyve got the right people making the right decisions, then adding the governance and the overhead that we might be describing is probably unnecessary. But if its those high failure rates that youre describing, then putting in some governance and some of that pain that youre describing, I think would be money well spent and pain thats worthwhile. Michael Krigsman: Todd Williams: Michael Krigsman: Todd Williams: Somebody on Twitter just asked the question: What steps can help set you up for project success? Can I take that? If you know. Im still trying to figure that one out for myself. So yeah. Go for it. There is no specific recipe that says: For this project to succeed However, there are a number of things you can do to make things better. Ill roll right back to Steves comment, which I commented on earlier myself, and that is throwing things over the wall. Too many IT organizations dont get involved with their customer. They dont know how the customer works. Theyre sitting in another room. Ive worked with clients where literally the IT organization is another building, across the river, across the state, in another town. So they dont even have the ability to go out and see how the business user does their stuff. So when the business user comes back and asks for some system, the IT group doesnt know, really, what they need. They have to go solely by specifications, solely by what is said. They dont have that feel. That cripples them, in not being able to make the correct suggestions to the business user, to be able to make things happen better. Divesting that IT group, so it is much closer and embedded in the organizations in the business organizations makes things significantly better. Because they understand. They have coffee. They
2011 Focus Research 7

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

talk by the water cooler. They have lunch with the people who are actually doing the work. They understand what has to go on. Michael Krigsman: Uh-huh. If you joined us in the last few minutes, were in the middle of a Focus Roundtable on IT project failure. And you can track this discussion on Twitter with the hashtag #FocusRT or the projectmanagement keyword on Focus.com. So Steve, what about this notion of communication? Is that really all that it takes get IT and the business people having coffee together? Steven Romero: (Laughter) (Crosstalk) Steven Romero: Thats a great place to start. I absolutely agree with the need for IT having an acute understanding of the business. And as much as theres a need for IT to get as great an understanding as possible about the business, their customers, their market segments, their culture, and how they work, and how they make decisions, I think its equally important for the business to learn more about IT, and learn more about how technology can be leveraged for business advantage. And thats where IT can help. IT can take a lot of steps not only to educate themselves about the business which I couldnt agree more. Its an absolute imperative. But, at the same time, they should be doing everything they can to raise what Peter Weill at MITs Center for Information Systems Research calls IT savvy, which is a combination of an IT organization that has a really good understanding of the business, and a business that has a good understanding of how technology is leveraged to meet their objectives and to meet their needs. So sure, it starts with maybe sitting at coffee. But Id like to see a much deeper dive than that. Michael Krigsman: So a deeper dive on communication, maybe even to some type of collaboration. And dare we say it? Maybe even some type of knowledge sharing, information sharing that goes across the lines of business silos with the IT silo. Hows that? Exactly. Thats ideal. In fact, right now more and more Gartner CIO Magazine. They spent a good part of the beginning of this year talking about how IT has to become a driver of business innovation. It has to be more involved with delivering innovation to the business, and not just within the walls of IT.
8

Having coffee together.

Steven Romero:

2011 Focus Research

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

And its ironic that its actually the participation in delivering those business innovations. When IT works with a business to go through the ideation and come up with ways of introducing that innovation thats where IT actually learns more about the business, and the business learns more about how technology can be leveraged. But it starts with, as you mentioned, that collaboration sitting down together and actually participating with one another. Michael Krigsman: Todd, you know all of this sounds great in theory. And in a way, its kind of obvious. But when I think back about the projects that I look at, that I analyze for my blog, for example quite frankly, this just seems insane. How can you take an organization that is heavily siloed, and get them to do any of this? Where would you begin? Give us just two or three pieces of quick advice here. Todd Williams: Well, it starts at the top. Okay? So if you take an organization like InFocus. Its actually a Portland company that just did a presentation at a local cinema event, and talked about how they rebuilt the company. It started with the CEO. And the CEO said, IT is gonna drive this. And IT, at that point because of that edict, IT then was able to get out and work with each individual organization, and look at where they had access databases, user-defined system, and was able to pull those back into the IT organization, and show where there was benefit. Because it was driven from that side. If you dont do that, then its IT having to go out and push. And that pull mechanism is much, much easier. So it starts there at the top. The CEO has to understand that IT is at the table. Theyre a critical part of the business. Theyre not just telephony; theyre bigger than that. Getting people then involved, and taking a group of business analysts and programmers and sending them out with the actual business user, and saying: This is who you need to help. And these are your goals then breaks down that silo. Thats where the CIO can actually make a huge change. Instead of having all the people that report to him or her in one building, get 'em out and dispersed into the actual group. Yes, its harder to maybe manage all of those people for the CIO. But its much easier for them to do what the business wants to do. And thats what were in the game of doing is supplying value to the business, not making a group of people easy to manage.
2011 Focus Research 9

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Michael Krigsman:

Steve, so what Im hearing Todd say is that you need to start with the business the lines of business and IT, developing some shared goals. What do you think about that? And how do you begin that process? If theyre a siloed organization, how do you start that? Right. And I get it. Wow. And its so interesting hearing that its even possible. Oh. No one is saying its possible.

Steven Romero: Michael Krigsman: (Crosstalk) (Laughter) Steven Romero:

No. I mean that its possible for an IT organization to be in a business, and have different goals than the business itself, when today thats probably not uncommon at all. Yeah. And thats where Ill lean heavily on IT governance. If the business takes responsibility for governing IT, which is the essence of IT governance it should more appropriately be named business governance of IT then things like strategic planning become integrated. So one of the major, major processes within IT governance is integrated business and IT planning, where neither one of those factions would either consider their goals, or what they were trying to achieve as an organization, without including the other. And just about every other governance process that I could talk about also insists on that collaboration. And thats what IT governance does for most organizations that are really getting into it for the first time is it brings to light how decisions are made, whos involved in those decisions. And one of the very first questions is: are the right people involved? We have to establish formal accountability. And in doing so, you review whos historically made those decisions. And you find, in one instance after another, these decisions are almost unilaterally made by the business. And all these decisions these are almost always unilaterally made by IT. Because when were done, I would want to see very few decisions that are made by just one of those factions. And what Ive found again and again and again is that as these committees these governance

Michael Krigsman: Steven Romero:

2011 Focus Research

10

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

committees are put in place, you end up with representation from both. Todd Williams: Yeah. We dont talk about just the idea that were saying it has to be integrated IT and the rest of the business. Do you ever hear somebody say, We have to integrate the planning the strategic planning for finance and the rest of the business? No. No. Thats exactly right. Thats why

Michael Krigsman: (Crosstalk) Todd Williams: Michael Krigsman: Todd Williams: Michael Krigsman:

The subject doesnt come up. Right. And we need to get to that point. Thats why this is so bizarre is because we treat IT so differently. In what other domain ? If finance said, Oh yeah. We had this project, and it cost us $100 million dollars, and were totally writing it off. Dont worry about it, I mean people would go bonkers.

(Laughter) But this happens with IT all the time. Steven Romero: Right. And I think weve grown used to it, unfortunately. It has so much to do with our history. And you guys have been in this game as long as I have. I mean when we started, we acted with near impunity and autonomy, and we were doing things that nobody understood. And the business was just happy to get one innovation after another. And thats changed markedly since our first beginnings. Its such a much more complex proposition, and it makes up such a more significant subset of the budget. And the types of products and programs were undertaking are so much more potentially expensive than they were historically. Now when things go wrong, they can go terribly wrong. And business has tried to do something about it. But theyve been so disengaged for so long. The lack of that governance that I spoke of earlier its why theres that huge gap right now. And I think weve just grown used to things going wrong in IT, and many people mistakenly just equate it to the nature of the beast. But I think those days are coming to an end.
2011 Focus Research 11

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Michael Krigsman:

How do you identify we have about 15 minutes or so left. How do you identify when not to take a project? Somebody asked this over on the project management page at Focus. Todd? When it doesnt make business sense. Can you elaborate on that? The question I saw it out there too. And the question was sort of framed towards a project manager, when its not really the project managers job to take the project. At least thats how I understood the question. If you get on a project, and it looks like its headed towards disaster, then you need to work with the project sponsors. You need to work with the stakeholders, and understand what it is that is making that not head down that road. Whats the value thats missing? Whats the difficulty here in getting the value? And then either helping make the decision that you need to cut the cord on this thing and let it go, or making the changes in it, so that it actually provides the value, and changing the scope scheduled budget to match that, so youll actually get that

Todd Williams: Michael Krigsman: Todd Williams:

Michael Krigsman:

But let me ask you a question though. So lets say Im a project manager, and I have been given a project. Ive been told, Please do this project. And heres your budget. And I look into it, and I realize, You know what? This thing has problems, and its probably not gonna work. And I go back to the boss, and he or she doesnt want to listen. You know what? I dont want to lose my job. I just want to do this thing. So Im totally stuck. And I think this happens all the time. What do I do?

Steven Romero:

Right. So the way I read the question was just that way that its a project manager. And theyre totally stuck. And what do they do? I think all of Todds suggestions are spot on. And there could be any number of reasons why the project manager is of the belief that its not gonna work. The only way theyre gonna possibly be able to overcome any of those issues and hopefully, thats the goal, to overcome those issues, whether it be to get people to realize that its doomed, or to actually take the steps required to rectify what might be dooming it is theyre gonna need a project sponsor.

2011 Focus Research

12

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

So if I was there if I was in that position, and Im the project manager, I would do everything I could to say, Im not gonna take any project, unless I have an executive sponsor who has a vested interest in the success of this project. Michael Krigsman: Wait. Again, Im sorry for interrupting. And pardon me. But here I am. Im the project manager, and Im going to the sponsor. And the sponsors saying maybe not in so many words, but You need to go do this. Because its a great project. And what do I do? Because, frankly, I dont want to lose my job. The economys still not that great. What do I do? Give me advice. Steven Romero: Okay. I see what youre saying. This sponsor is ignoring all the constraints that were describing or the issues or the risks? Is that also something I can assume in this question? Yeah. The constraints that I, as a project manager, believe are there. Because obviously he or she doesnt see those constraints, or is not acknowledging them. What do I do? Right. Todd, youre gonna have to help me out here. Because all I can think of is updating your resume.

Michael Krigsman:

Steven Romero: (Laughter) Michael Krigsman: Todd Williams:

I dont want to update my resume. Todd, save me. Please. Well, you know I have this phrase that you cant help anyone, until they realize theres a problem. And anybody whos been through Al-Anon or AA realizes that until the person realizes they have a problem, theres nothing you can do to help. Okay? You can only sit there and make resources available to them, to see that a problem exists. You cant take 'em beyond that. So what I end up doing, in those situations and Ive been in more than one is put in front of them: Here are the facts. These are highly emotionally charged situations. So you need to try to remove yourself from the emotion and just start laying out facts.

Michael Krigsman: Todd Williams:

Uh-huh. You need to make it so that this person comes to the realization that theyre in trouble, that there is a problem and that theres a way out of it. If you just go and say, Problem. Problem. Problem. Problem, and dont say, Problem. But we could do this. Problem. But we could do this.
13

2011 Focus Research

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Problem. But we could do this then they start to see that way out of it. Okay? But you have to deal with fact. You have to pull that emotion out of there. Michael Krigsman: So Steve, give us two or three succinct bullet points for: how do you build the business case that Todd is describing to go back to that sponsor and say, Boing. Boing. Boing. We need to do this, or not do this, what have you? What do you need to have in that business case? And by the way, if youre a project manager, and youre out there listening, listen closely to this. Because you need this stuff. Steven Romero: So it sounds like you almost want to make revisions to the existing business case. Is that what you mean? Because theyre not gonna unilaterally a project managers not gonna it might be semantics, but the project managers not gonna unilaterally change the business case. I mean its the business case that I was assuming the project manager found in error that there was something wrong with it. Michael Krigsman: Steven Romero: Yes. And looking at this business case, they cant possibly succeed. And if thats the case, thats where Im gonna do and I guess youre looking for something besides what Todd just mentioned. And I would say that and it gets back to those three things that I mentioned earlier. I am going to document the constraints. I am going to document the issues. Im going to document the risks. And I liked what Todd said with as much fact as possible, with as much detail as possible, and get that to that project sponsor, in the hopes that they look at those things, that theyre credible, that I can convince them that theyre actually going to keep this thing from ever succeeding. And hopefully theyll respond to those. And well either find that we can modify the business case in response to those constraints, those issues, those risks that Ive listed, or abandon it altogether. So I dont know what you were looking for, besides what Todd suggested. Because I thought that was a great list of bullets to go forward. What are my constraints? What are my issues? What are my risks? Get those back to the people that are gonna make the decisions, as quickly as possible.
2011 Focus Research 14

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Michael Krigsman:

No. That sounds exactly right. And another thing that he said is to come at it dispassionately. Pull the emotion out of it, and build up a strong analytical case that, as you say, lays out the facts and lays out the constraints, and does it concisely and as clearly as you can possibly make it. I think thats right. I think thats your best shot, if youre a project manager.

Todd Williams:

Yeah. I mean you brought up the business case. If you have a specific thing, and you say, Hey, this business case doesnt work anymore, then prove it. Go out to the people who made up the business case and say, Youve got this set of things. Look at your assumptions that made up that business case. Because thats probably what fell apart. And can we justify those assumptions? Oh. Excuse me, sponsor. It looks like we made this assumption, and its no longer valid. Gosh. Isnt that horrible? And now the sponsor has an out. Okay? So now youre into: how do you play the card game? Right? Because you dont want the sponsor to, all of a sudden, be the bad guy. You dont want to make anybody look bad. Right? This whole if youve read my blog, the whole blame thing needs to go away. So if you give the sponsor an out of saying, Oh, here is an assumption that went wrong. So it was a bad assumption. Or not even a bad assumption its not valid anymore. Now youre coaxing that sponsor down a route of Oh, I see. This changed. Okay. How are we gonna handle that? Now youre managing the project.

Michael Krigsman:

Sounds to me like also whats implied in this getting back to what you said earlier about communication is you are engaging, in a very serious way, a committed way with the line of business with the business folks, in order to do that. Absolutely. And theres another pitch for product in portfolio management. And this is something that I seldom see. But when Im talking to organizations about project and portfolio management, I throw up a sample business case bullet list. And its got a lot of the things on that list that I dont necessarily see when I visit organizations, and they have templates for business cases. And a lot of the things have to do with the business changes that need to take place, the business sponsorship that needs to take place, the

Steven Romero:

2011 Focus Research

15

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

executive value oversight, which gets back to that question earlier about what does the project manager do with a business case that they know is terrible? Its one thing to go to the project sponsor with good product and portfolio management constructs in place. Somebody within that investment decision making body that executive steering team has to raise their hand, when this project or program is sanctioned, and say, Okay. Its me. Im gonna be the one thats responsible for value delivery of this investment. So Ill be coming back, at regular intervals, with updates as to whether or not this product or program is on track to deliver everything we said it was gonna deliver, or if we see any evidence that those benefits are being eroded, and we may not realize that value. When you have that type of executive accountability in place, the project manager has somebody to talk to, and has somebody to go to. And that person also is there to answer to the business. Because if the business is waiting for it, they can go to the project manager and ask him how things are going. But if Im on the business side, Im gonna go to that executive thats responsible for value delivery oversight and say, How are things going? How are things working? And there has to be a very strong linkage and a very strong partnership for that to even take place. Michael Krigsman: Todd, Ill bet that in many of the projects you see, that are going off the rails that youre called in to turn around Ill bet that kind of clear definition of accountability of the business case, and of the value is lacking. Well, at the time I normally come into a project thats in a state of disarray, if wed like to put it politely, its all finger-pointing. Its all blame. People are running for cover. Theyre trying to hide. Theyre trying to disassociate themselves with anything. Because theres a whole bunch of blame thats going on. When you look at what weve been saying, its been communicate with this person. Communicate with that person. Communicate with that person. When you get to that point of saying, Communicate. Communicate. Communicate, youre now talking about: how can you make interpersonal skills work? Right? Michael Krigsman: Uh-huh.

Todd Williams:

2011 Focus Research

16

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Todd Williams:

And as far as Im concerned, project management is 75 to 80 percent interpersonal skills. So now whenever I walk into something thats in total disarray, its trying to take all of those people that are out in there own little scurrying for cover, and bring them all back together as a team. And then figure out what that solution is. Thats very different than having a project that is going off the rails, and people dont realize it yet. Because by the time Im brought in, realization has happened. Somebody has said, Oh, were in trouble here. Right? So they are two distinctly different things. And coming in to fix a failed project is much easier than taking a project thats starting to drift off track, and bringing that to light, and getting the realization, and keeping your job.

Michael Krigsman:

I assume that the reason for that is because while its sort of hidden still going off the rails, but hidden you dont have as much to work with. Is that true? Well, youre also working with ego and emotion. And people arent willing to say, This is my baby, and its in trouble. Theres, once again, that hiding from the blame. So when things are starting to go off the rail, people dont necessarily want to admit it, for any number of reasons. So we have five minutes left. Steve, you want to maybe take a stab, and give us a few practical steps to take? Lets say while the project has not yet blown up totally. But you have a project, and the project manager has a sense that theres a problem. What are a few ideas to help? Right. First and foremost, its communication. Its having the facts. And weve said a lot of things already not speaking with emotion, not speaking in generalities, but having the facts, and then taking them to the people who need to hear that information, and hear that bad news as quickly as possible. And it gets a little bit to the conversation that weve been having. I don't know how much weve actually touched on it. But it has to do with culture, and how the organization responds to bad news, and how the organization responds to failure. I mean Todd mentioned it. Many times, he comes into the situation, and everyones pointing fingers and laying blame. And the question would be: why is that? Why arent they looking at indicators of things going wrong, or failure as a state as just a bit of information thats been used to take corrective action? As opposed to failure used as an indication that someones to blame, that someones at fault, and Were gonna find out who that is.

Todd Williams:

Michael Krigsman:

Steven Romero:

2011 Focus Research

17

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

So depending on how the enterprise treats the word failure, as to whether or not its just a flag, a checkpoint, an indicator or, again, is it something that were gonna use to cast blame on somebody, and make sure somebodys head rolls? If someones heads gonna roll, its gonna have a huge impact on what a project manager does in response to those indicators that something is going wrong. So hopefully the project manager is working in an environment where they dont shoot the messenger, where it pays to provide that information that accurate information of whats going wrong, and getting it to the people who can do something and take action, or listen to your recommendations and approve them give you more money, give you more time, whatever the solution might be to get that project back on track. But its back to the same things weve been saying stating facts, removing emotion, and calling a spade a spade. And hopefully theyre working in an environment that responds to that bad news as a means of doing something, as opposed to looking at that bad news and saying, Okay. Youre fired. Michael Krigsman: Todd, were gonna give you the last word. A couple of pieces of advice give us a couple of pieces of advice for project managers or CIOs who might be listening. Well, if things are starting to go awry, or if you have things that are awry weve already said this and its somewhat of a stuck record dont assign blame. That just doesnt help anything. Remove the emotion. And if you have to, bring in somebody new, who doesnt have emotion. Because too many times, theres a lot of emotion around. Third, dont work on symptoms. Too many times, we say, Oh, theres scope creep. Weve got to go solve scope creep. Well, no. We need to find out why theres scope creep. Is it because we dont have the value? Is it because its not providing some function that I need? Lets go drill down to that, and actually find out where that problem is, and address that specific issue. Those are probably the three top things that I would say you need to take a look at. Get involved with the customer. Its not an IT project. That was another question I saw floating around out there is something about IT projects. These arent IT projects. Theyre business projects. Its just that ITs involved, period. Michael Krigsman:
2011 Focus Research

Todd Williams:

Yeah. Technology enabled business projects. Thats how I


18

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Steven Romero: Todd Williams: Michael Krigsman:

I like the sound of that. Yep. Its a little buzzword-y and jargon-y. But, actually, theyre business projects that happen to involve technology. And thats the right way to look at it. Isnt it? Every one of them. Great. Well, I would like to thank Steve Romero, who is an IT governance evangelist with CA Technologies, and Todd Williams, who is the president of eCameron, Inc. and author of a new book on turning around IT projects. All of these questions are gonna be posted on Focus.com with the keyword projectmanagement. So please join us over there to continue this discussion. And the recording will be posted within 24 hours. And therell be a transcript of this call up within a week. Thank you so much for joining us. And Id like to thank my two experts for taking the time and creating a great conversation. Have a great day.

Steven Romero: Michael Krigsman:

Steven Romero: Todd Williams: Michael Krigsman: Steven Romero:

Thank you. Thank you. Thank you. Bye-bye. Bye-bye.

2011 Focus Research

19

Focus IT Roundtable: How to Recognize and Prevent IT Project Failures

Michael Krigsman
CEO, Asuret Inc. http://www.focus.com/profiles/michael-krigsman/public/

Steven Romero
IT Governance Evangelist, CA Technologies http://www.focus.com/profiles/steven-romero/public/

Todd Williams
PRESIDENT, eCameron, Inc. http://www.focus.com/profiles/todd-williams-1/public/

2011 Focus Research

20