Leadership

How to kill a major IT project without killing your career

If you plan on being a good IT leader, you'd better be able to not only survive problem projects, but know how to use them to demonstrate leadership and to build political capital with your peers.

Meet Christine, the CIO at a midsize manufacturing company. Christine is a year into an 18-month, $2 million SAP expansion, and, to put it mildly, things aren't going as planned. In fact, the real problem is that this project is never going to go as planned. We'll join Christine's thoughts as she makes her way to the quarterly steering committee meeting to deliver the bad news.

"I can't believe I let those guys at SAP talk me into adding a bunch of new modules onto this system. I should have known the software wasn't ready. They just acquired it as part of the purchase of a couple of companies, and it's clear they are still trying to integrate the new code into the core SAP modules. I could kick myself. I really, really should have known better. Things never go smoothly after an acquisition.

This was supposed to be a quick win and a simple integration to meet my customer's needs. Yeah, right. This project is going to take an additional six months, and, worse, it's going to cost us another $2 million.

How am I going to tell the execs we're in trouble, and we need to consider cancelling this project?"

Sound familiar?

What senior IT leader hasn't had to face this challenge? If you were lucky enough to avoid the ax, it probably cost you a raise or a bonus. But worst of all, it hurt your credibility with senior management.

So how do you handle a situation like this? How do you kill a major project without killing your career?

Before we solve Christine's problem, let's take a closer look at Christine and her situation.

Sure her project is in trouble, but is success as an IT leader contingent upon never having a troubled project? Is it really possible to expect the IT leaders of large organizations to never have to deliver bad news? Come on.

Information technology projects are always pushing the envelope in an effort to support the business. There are going to be failures, period. What sales or marketing group can claim 100% success on all programs? So if you plan on being an influential IT leader, you'd better be able to not only survive problem projects but also know how to use them to demonstrate leadership and to build political capital with your executive peers.

Christine is in hot water for a few reasons, none of which has to do with the specifics of the project.

  1. Christine cares about her work and her reputation. She doesn't shy away from personal responsibility and she is keen to bring that same personal responsibility to all the company's IT projects. And that's the problem. She mistakenly thinks (and acts) as if she is personally responsible for all IT projects. [Note -- I said personally not professionally. There is a very big difference.]
  2. Christine is a first-rate IT project manager. Her projects never fail. She knows how to prepare for project success, but doesn't have a clue about preparing for failure. Not her failure, mind you, but the project's failure.
  3. Christine is a visionary and can see the great benefits the project will bring the company, and she's excited about the possibilities. Unfortunately, this excitement translates into Christine becoming a major advocate and supporter of the project, which makes it hard for her to shut down the project without looking stupid.

Sure the SAP project is in trouble, but the real problem is that Christine has become the project. To effectively deal with problem projects -- and every good IT leader is going to have them -- you have to stand separate and apart from the IT projects you are charged to oversee.

You have to change your understanding of your role vis-à-vis the IT project portfolio. You have to recognize that as the CIO, your job is not to be the project manager of every IT project. And stop acting like the project's biggest cheerleader. Don't get so personally invested in the project. Remember the real focus of your job as the CIO is to get the right projects done in the right way, for the right price.

From the very start, yours should be the voice of concerned risk management. Be the skeptic. Ask the tough questions like: Will this work? Can you really do that? What if things go wrong?

Let the users, the more junior people on your team, and the vendor prove to you that everything is really OK. Your job is to highlight the risks until the project is up and running smoothly. Challenge the project team to meet their stated objectives.

And most importantly, don't position yourself as the person presenting the project to your peers. That just sets you up to be the object of their criticism. Instead, get on their side of the table. Be part of the team reviewing the problem project, not the person delivering the bad news.

Unfortunately, Christine didn't do that, and she's really in a jam. She still has no idea what to say to the steering committee, and that sinking feeling in the pit of her stomach just gets worse, the closer she gets to the conference room. Christine could sure use some help.

As she rounds the corner to the executive suite, she bumps into Martin, her trusted consultant, who's just finished running a successful, large-scale data warehousing project for her.

"Martin, I'm so glad I ran into you. I really need your advice. I need to kill this project. It's gone horribly wrong," she said, filling him in on the problem. "What should I do?"

Next time, we'll listen in as Martin gives Christine some advice.

Marc J. Schiller is a leading IT thinker, speaker, and author of the upcoming book The Eleven Secrets of Highly Influential IT Leaders. Over the last 20 years he has helped IT leaders and their teams dramatically increase their influence in their organization and reap the associated personal and professional rewards. More info at http://marcjschiller.com.

54 comments
bhawks1028
bhawks1028

What I would like to know is why the project plan failed to identify the major milestones that are supposed to recognize failure points. If the project was scoped correctly and reports to upper management that all milestones are being met is what has been conveyed the the fault lies SQUARELY with the PM (Christine). If the milestones of the project did not disclose the issues then its a poorly written project plan and again the fault is on the PM. You could go as far as to say that the support/initialization team did not disclose the lack of knowledge when discussing the project in its first phases, but if they are into rolling out into production then they must have moved through a valid development and testing phase yes? A company this size would have some sort of ITIL framework or at least a change management team since the article disclosed a steering committee. Either the in house IT team did not disclose issues during test or they had no idea what they were doing in order to get approval to roll to production. I would think that Christine is in serious trouble no matter what side she sits on. She did not due her due diligence.

gnorton100
gnorton100

As the CIO, Christine is IN the chair labeled "The buck stops here". IF she's actually a leader, she takes responsibility for the success or failure of each project. If she's actually a leader, she involved all levels of the company in the feasibility portion of the plan, brainstormed to determine possible pitfalls and made plans for them, and set realistic timelines and reporting requirements for all levels involved in the project. I agree with the earlier post that suggested the CIO should let the PM run the project. An old Navy saying: "you get what you inspect, not what you expect" also comes into play. The inspection comes from scheduled reports(monthly)and the requirement that any problems be reported immediately along with options for dealing with the problem. This permits growth of PM skills, allows the CIO to be a CIO (not a PM) and hopefully empowers all those involved in the work, which leads to personal ownership and the desire for a successful outcome.

dalma95
dalma95

great insight... should implement these ideas into government institutions as well to make them more efficient and cost effective

Hugo J
Hugo J

Why did this happen? How come that an experienced CIO took this decision? From my experience it tells me that this company probably does not have an IT strategy aligned with the business strategy. If you do not have a correct IT strategy where top management are the decision makers in major IT interventions then you should better start developing one. The IT strategy shall describe the relation between business and IT. How decisions are taken, the responsibilities, budget etc. In the case described what business purpose had this IT project? Why did the business need these modules? Was the need important, urgent? If the need was not important then I should say that she did a really bad business decision. It has nothing to do with IT. If the need is important and urgent then one could justify to try an implementation of new modules if top management are aware of the high risks involved. And who signed the contract with the supplier? Is sourcing involved or does the CIO sign the contracts herself? If the company has taken all the risks and the SAP guys send their invoices then they should also changing the way they source the IT services.

mcswan454
mcswan454

Sorry about multiple posts. It finally hit me... From the Author: "You have to change your understanding of your role vis-a-vis the IT project portfolio. You have to recognize that as the CIO, your job is not to be the project manager of every IT project. And stop acting like the project's biggest cheerleader. Don't get so personally invested in the project. Remember the real focus of your job as the CIO is to get the right projects done in the right way, for the right price." Simply put, you don't do an IT project for the sake of doing a IT project. I'm not certain now that we need the rest of the article. This situation, with effective IT leadership, NEVER had (nor has) to happen.

mcswan454
mcswan454

I revisited this. Curious, as I wanted to see what others had to say. Then I re-read something -- the first paragraph -- which really makes me believe this isn't a case study as much as a way to cover your arse if you're dumb enough to get yourself into this situation. It's decidedly not plausible in a real world environment. Why? This person wouldn't (couldn't, shouldn't) have employment. Think about it. As stated: "In fact, the real problem is that this project is never going to go as planned." Christine has had this project running for 12 of 18 months. Someone else said that you wouldn't wait 2/3 of the way in to notice things are going wrong. And bottom line, it will not ever go as planned. Perfect sense. Let's believe (notice I DIDN'T say assume) she's had to deliver status reports prior to this, EVERY QUARTER as stated in the article: "We'll join Christine's thoughts as she makes her way to the quarterly steering committee meeting to deliver the bad news." She's been to the committee thrice before to deliver status on the project. Not assumed, as we are told it's been a year (4 Quarters) of 18 months. Questions: a) Has Christine been lying about this project until now? At least twice before she's had to tell the steering committee the status. I'm guessing things were going "well" to this point? b) Has Christine been paying ANY attention to the project? Or has she been on the other side of the table? Again, up to THIS point. I'm guessing things were going "well" ? c) Have you ever REALLY been this shady in your dealings with your own company? 12 of 18 months, and she's just noticing NOW things aren't going right? At some point, this expansion project became a disaster, and our intrepid CIO was asleep at the wheel, or blatantly lying. Read the article again without forming an opinion. Or did I come down hard on her by REALLY reading this story? It bothers me because of this statement by the author: "Let the users, the more junior people on your team, and the vendor prove to you that everything is really OK. Your job is to highlight the risks until the project is up and running smoothly. Challenge the project team to meet `their` stated objectives." When in this discussion were we told that this project was an idea of ANYONE other than Christine? I'd like to know. The project team must meet THEIR stated objectives? The project team DIDN'T have an input into this turkey!!! Christine was the one who was convinced to do the project by her OWN admission: "I can't believe I let those guys at SAP talk me into adding a bunch of new modules onto this system." I'm placing money down the project team would've objected like nobody's business that this was unnecessary. However, there are some perks to being CIO, such as: Do it, or your fired, cause this is MY project! (Sound familiar?) As another poster stated, they probably had not bought into SAP 100%. It makes sense. But this turkey, after re-reading, was all the CIO's fault. There was no valid business reason to do this. While she states: "This was supposed to be a quick win and a simple integration to meet my customers' needs." I doubt heavily that her customers needed the expansion. Doesn't she chastise herself: "I can't believe I let those guys at SAP talk me into adding a bunch of new modules onto this system. I should have known the software wasn't ready. They just acquired it as part of the purchase of a couple of companies, and it's clear they are still trying to integrate the new code into the core SAP modules. I could kick myself. I really, really should have known better." She should fail, and fail BIG TIME! She's earned it! And NO ONE should go down with her. She brought this upon herself. Even she admits that she knew the project wasn't a good idea. And, I'm so SURE the project team was able to convince her that this was a needed step: (We need to justify our salaries for a few months. Can we F'up something for about a year so we can stay off the unemployment rolls? Economy's not so good right now.) I can only guess how she sold this to the steering committee, other than her title -- CIO. This is a textbook failure, and should be treated as such: No mercy. But as said earlier, the next article(s) WILL get her out of this without losing either credibility or position. It probably will also reek of something unsavory, because if you read this story a couple of times, you know Christine deserves to lose. Still, with some good spin, she might even get a raise! Let's see what Martin has to say. Myself? I think I paid too much attention, and some poor sot is going to get the crucifix. M.

marcjschiller
marcjschiller

I love it when an article creates a whole lot of energy and response. And from the "energetic" comments above, it's clear this issue is a very real for many of us and it generates an awful lot of emotion for some. At first, I planned to respond to each comment individually but as I watched the discussion evolve, I found many of the answers emerging on their own. But even with the many excellent answers presented, I do have a few points / clarifications to add to the discussion. I especially want to focus on the "criticisms" I think I heard, they go something like this: 1. Leadership is about taking responsibility, you're advocating "passing the buck" to the junior staff. 2. No big project ever get's done without senior people taking responsibility. Christine has to "stick her neck out" to deserve the title she carries. 3. IT project mistakes happen, you gotta be able to "fess up" and quick, hiding mistakes just makes things worse. 4. How can you advocate "getting on their side of the table" and abandoning your IT team members. What kind of a leader is that? I suspect that a number of you who drew the above conclusions missed the fact that this article is about leadership NOT project management. Let me repeat, CIO leadership not CIO project management. In fact, that is exactly the problem. Too many CIOs (with a rich and successful career as IT project managers) can't get their hands out of IT project management. And they justify their over involvement and micro managing with the very points presented above. To be a real CIO you have to empower your people. You have to give them the opportunity to really lead projects and you have to be there to support and back them up when the sh_t hits the fan. When the CIO is the face of the project to the steering committee she looses her ability to back up and support her people ON the steering committee. When the CIO is nothing more than the lead techie in the room that now has to step in and fess up for any and all IT mistakes as soon as they happen, then the CIO has no strategic influence or power to drive a meaningful agenda. Great IT leaders invest in building the credibility and reach of their senior managers. They work with their CxO peers to connect their team members and to jointly support them on projects. If the CIO takes on the role of default lead project manager (which so often happens) than what's left for the senior PM to do? Tag along to the meeting and answer detailed questions while the CIO takes the heat? Come on guys, we have all seen this 100 times and it is the most common pattern. It's unfortunate that so many of us have come to think that is the definition of responsibility and and support. Can you imagine a similar scenario in sales? Would the VP of sales be jumping in to take hold of a major sales initiative gone sour or would they be working and supporting their directors and sales managers and coaching them through the difficult process. It's just that we have become so accustomed to a dysfunctional IT management model that we actually believe its correct. This article is an attempt to lay it bare for all to see. There are CIOs who get this and do things very differently and I have seen them achieve astounding success for IT, their teams and themselves. Very often they are CIOs who do not have a background in IT and therefore are completely reliant on the IT expertise of their people to succeed. This situation FORCES them to stay out of the nitty gritty of the project and instead focus on supporting their people, supervising the adherence to IT governance process and enhancing the relationship between IT and other functional areas. As many of you have pointed out (special shout out to dwerhart, JamesRL, OldFartIV, Jenny Sutton, and grandslammaceking) there are a number of thoughtful ways to handle the situation without throwing yourself under the bus and taking over. It's tempting, I know, but take a deep breath and pause. Rushing to "fess up" immediately is the absolute right thing for the PM to do, the question here is what should the CIO be doing. I'm sure the discussion will continue when part two comes out next week. Keep 'em coming and may your career be blessed with many "interesting" moments like Christine's.

grandslamaceking
grandslamaceking

Christine needs to stand back and see if she has done her homework - risk analysis, vendor review of causes for delay etc., potential cost increase, impact on other projects, project benefits etc.and lay all of this out in front of the steering committee (who on assumes are no fools), with a recommendation as to how to proceed or reduce scope or cancel. Having been in this position a number of times in 40 years of IT management of major projects, they must be part of the decision and may decide to proceed. However before going to the Steering Committee get the project sponsor onside with her recommendations and do not come up with this approach on her own without having her team(s) involved and SAP!!!

romank
romank

Whether this is a small, mid or large size organization. I would never hire a CIO with this type of attitude. Risk should be assets at all levels and presented to CIO. Who in turn presents portfolio to the steering committee.

JasonKB
JasonKB

As others have pointed out, good PM practice should prevent this type of situation. There is no way a good PM should get 2/3s into a project before realizing it is going so bad it may have to be canceled. There should have been many signs that this was off the rails months ago. What might I do in this situation? Apply the principle that people like to hear solutions, not problems. I would work out a few alternative scenarios for presentation to the steering group: 1)New milestone dates and cost to complete with scope as-is. 2)Reduced scope based on existing time line and expense budget. 3)Partially expanded scope to meet minimal requirements with new time line and budget forecast. if possible each scope deliverable itemized by cost and delivery date estimates. This gets everybody focused on resolution rather affixing blame. What will she do? One scenario... 1) Express great dismay to the steering group that this just came to her attention... 2) Find a scapegoat (medium level contributor, independent thinker, chronically late on expenses paperwork), fire this person amid allegations of theft or embezzlement. (Once someone is labeled a thief, people will assume the guy is capable of ruining the whole project himself.) 3) Hire replacement who is combination lapdog, yes man and department snitch. 4) Bring in expensive consultants to "save" the company from disaster due to the ramifications of this project failing. 5) Claim great "disaster prevention" accomplishments on her review.

mcswan454
mcswan454

"Meet Christine, the CIO at a midsize manufacturing company. Christine is a year into an 18-month, $2 million SAP expansion, and, to put it mildly, things aren't going as planned. In fact, the real problem is that this project is never going to go as planned." I am probably wrong here, but why am I sensing that this project was ill-conceived at inception? The implications of the first paragraph are that regardless of how much or many resources we throw at it, it is doomed, an abject failure. This project, perhaps, should NEVER have been contemplated... "I can't believe I let those guys at SAP talk me into adding a bunch of new modules onto this system... I could kick myself. I really, really should have known better. Things never go smoothly after an acquisition. This was supposed to be a quick win and a simple integration to meet my customers' needs. Yeah, right. This project is going to take an additional six months, and, worse, it's going to cost us another $2 million. How am I going to tell the execs we're in trouble, and we need to consider canceling this project?" While I'm certain the rest of the article will tell us how she gets out of this mess, WITHOUT being fired or losing credibility, the idea that "Is this trip REALLY necessary?" suggests the project wouldn't have delivered ROI from Day One. Effective leadership and project management probably would NEVER have allowed this to go forward. It sounds like what she said: "I can't believe I let those guys at SAP talk me into adding a bunch of new modules onto this system." This was, (is) an unnecessary project, that NOW can take down a career. It will be interesting to see how she gets out of this, and a lesson to the rest of us how to avoid being in this spot in the first place. Projects fail; we know that. But somehow, I get the feeling the end result will be the 7 P's: Proper Prior Planning Prevents Pi**-Poor Performance. You can always say "NO". M.

grandslamaceking
grandslamaceking

Christine needs to stand back and see if she has done her homework - risk analysis, vendor review of causes for delay etc., potential cost increase, impact on other projects, project benefits etc.and lay all of this out in front of the steering committee (who on assumes are no fools), with a recommendation as to how to proceed or reduce scope or cancel. Having been in this position a number of times in 40 years of IT management of major projects, they must be part of the decision and may decide to proceed. However before going to the Steering Committee get the project sponsor onside with her recommendations and do not come up with this approach on her own without having her team(s) involved and SAP!!!

Englebert
Englebert

The worst thing one can do is operate in a state of denial, attempt to defend, protect oneself, play politics, please those in power...Such tactics have brought down entire corporations (Lehmann Bros). Leadership is making the tough decisions, owning up to faults, correcting the errors, striving to do better, guiding, listening, boosting morale...

ibrahim931
ibrahim931

you must have self-confidence and encourgment to say the truth. dicuss that failur woth you management as follow: talk about your previous succeful projects and your success in this company. secondly, admit your mistakes because you act as personally responsibility and.... thirdly, tell them you are Ready to bear the consequences.

Jenny Sutton
Jenny Sutton

Great advice - a key reason that too many projects limp along till the end without delivering the value promised is because the sponsor is too closely identified with the delivery and doesnt want to appear to fail. Distance and objectivity is key. Jenny Sutton - Author "Extract Value from Consultants"

Ian Thurston
Ian Thurston

I feel as if there are people from two different worlds talking to one another here. In one world, let's call it "Murphy's World", things go wrong all the time. People expect that, and even plan for it. They have to deal with failures, and their job is in part to minimize the costs and revise plans based on what they learn from "failures". In another world (with which I have no personal experience) EVERYTHING goes according to plan - and at the first whiff of smoke, everyone gets the hell out of Dodge. No one learns much from experience, but their resumes look REALLY nice.

adrianhorod
adrianhorod

There are a few options that come immediately in my mind: 1) Look for a better job as long as this project is positive on your resume ( your successor will happily kill it as soon as he gets the job). 2) Go to the management and present the situation ( make it look as bad as possible)and hope for mercy. 3)(my recommendation). Make a plan B meaning : - phase out whatever is not mandatory ( phase 2 , 3 , never). - replan with small , real , palpable deliveries to the users ( even at the costs of interfacing with the pld system , etc). - Redesign the budget so that at least the minimum will be in the budget. - Identify and emphasis the advantages of what you can deliver. - try to cancel/delay the implementation of not mandatory modules and redraw the contract with the supplier accordingly (they need your success too, a failure is not good for them). - Do this with your best people tomorrow morning ( or today) and take their commitment to the plan. - Present it to your management and bring your people to the meeting ( they need to here the management and vice versa). .. and acouple of additional comments : The CIO can not avoid full responsibility for a major enterprise-wide project. A scapegoat will not help. If you are a CIO , divide everything into phases and make sure that you have milestones in between to reevaluate the situation. Milestone means a complete delivery to business, even a small one. It helps when you get into troubles. They know you deliver. -

The 'G-Man.'
The 'G-Man.'

One question, why? The bunch of new modules would no doubt be outside the scope of the project so why add them now. She just saw the quick win and praise for said 'bunch of new modules' and forgot the chance of failure and increased cost.

dreusrequeza
dreusrequeza

There is a reason why the drawing board does not use the "permanent marker" as its matching pen, rather it has a special pen and an eraser that goes with it as its accessories. There is nothing wrong with sitting down "again" and re-thinking each step of the project. It is not an easy task to face, but it is more difficult to hide a rotten prawn shell than just cleaning the mess up. Layout your cards, don't bluff, this is not poker! Leadership per se, not only IT Leadership, comes with great responsibility, in both personal or professional perspective. There's a lot of ways to skin a cat - killing the project is just one of it. You're the CIO, be creative, find ways!

simon.robb
simon.robb

It's been done before...don't think the steering committee are naive. Yet you don't need to tell them who stuffed up unless they get involved in a post project review. Maybe also consider a career in stuffing chickens as your Project Management skills don't stand up for much! I Would sack SAP and move to Oracle :)

darije.djokic
darije.djokic

You let the steering committee decide, of course, with something like: Unfortunately unforeseeable technical difficulties arose; the completion will require at least another 6 m. and 2 Mbucks; do we waste that or kill the beast?

Old-Fart-IV
Old-Fart-IV

My humble $0.02 based upon the information provided: "I can't believe I let those guys at SAP talk me into adding a bunch of new modules onto this system ... This was supposed to be a quick win and a simple integration to meet my customers needs." I've been in this position too many times and had to fight tooth and nail on this issue. For project that I have managed, there is a change management process and it is there to ensure that "we" communicate proposed changes with those who control the "resources". If you want to change the project scope, document the change request with all the pertinent information: additional costs (people, schedule, HW, SW, etc), technical risks/assumptions and expected benefits. The project sponsor and stakeholders need to be aware of the impact a simple change can have on the promised delivery -- surprising them with bad news is the way to build trust in your ability to manage projects :) Edited before the gestapo caught my errors ... JR

mafergus
mafergus

Refocus on other priorities. That cumbersome SAP bolt-on becomes the focus for phase II improvements. You tie other pieces into the new WIN 7 migration and you "combine" major server components from the SAN WINTEL and UNIX groups. Then you quietly develop a new system to tie in those who haven't been SAP'd yet. All of this plays with Mike Hammer in the backgroud saying, "The 8's get it and the 3's don't"

JamesRL
JamesRL

The PM maye have an opinion and may have an idea where this project should be headed. But before she can pull the plug, she needs to sit in front of the sponsors and lay out what has changed in the value proposition. The sponsors presumably had a set of business reasons for doing the project in the first place. Christine needs to be able to review what those were, and explain whats changed, and then let the sponsors of the project make a decision. I had a real life situation happen where one of the major costs of the project had been left out of the business case. They had assumed the maintenance costs for the software would stay the same after the major upgrade, and it became clear at the end of the definition phase that they would dramatically increase. My counsel was to lay the business case in front of the sponsors again, with the new numbers, and ask if it still makes sense (alternative was to stay on the old version longer). The benefits were there, but since the costs were higher, the final decision was to kill the project, and rightly so. The PM didn't take it upon themself to make the call, it was up to the sponsors, as it should be. James

Tony Hopkinson
Tony Hopkinson

like that get off the ground without the CIO championing it? This is why you don't sign things straight after the nice meal the vendor paid for. Listen to your people not theirs, sheesh. Every minute you dither dodging the deserved responsibility for this mess, you are pouring the firm's money down a rat hole. Get off your arse and do your job. If you had some poor twonk you could foist this one off on, poor guy would be staked out in the car park right now wouldn't he? Pathetic.

maclovin
maclovin

Somone thinks about all the help that a project could bring an organization without considering time and labor of the individuals that actually have to DO the project. This is another example of the faults of IT Leadership, and their inability to understand the ways of current technologies and configuration of said items. The first comment posted is absolutely correct! (Pass the buck!! Thanks, we appreciate it!) As the CIO, that's ultimately where the answers need to be answered. Period. If you can't fess up to a mistaken promise, you shouldn't even be on a helpdesk.

abear4562
abear4562

So, the best advice you can give is pass the blame down the line to your own people by giving them impossible goals and asking them to meet the goals? That's a good way to gain their respect. How about just saying that the project isn't going well due to the reasons given, its time to cut the losses, and leave it at that? Shifting blame to your subordinates may work once or twice, but not more than that, and it really makes you unpopular with your own people, and gets them looking to stab you in the back. Seriously, if that's the best advice you can give, you should get out of the business.

Tony Hopkinson
Tony Hopkinson

learn scapegoating, blame spreading and accountability dodging. The number of times they've successfully failed, they've had plenty of practice.

dreusrequeza
dreusrequeza

It just hit me... Now I know why more and more organizations fail, and why more and more projects do not result to a successful delivery and closure. We have lost the understanding of what true and genuine leadership is... "Leadership by Example!" Yes, as CIO, as a "leader", you should be focused on the "bigger/braoder" aspects of stuff, and let the experts handle the "smaller/more detailed" parts of projects or so, but it doesn't mean that you are EXCUSED NOT TO KNOW the "nitty gritty". That is why Christine was easily "sweet talked" by SAP. She probably has no idea as what these modules are (atleast on the nitty gritty part). I have heard and read articles where they put in great detail the difference between a "Manager" and a "Leader". "Leaders guide, while Managers navigate...so on" (sounds familiar?.) I think they over did it. Big time. And people have been taking shortcuts to their career because of this concept. Ladder of the organization... the first step of that ladder is where you start, working your way up. And when you are at the top, when you are CIO, where you have brought your foundations with you, nobody can tell you "Buy this and it will solve you problems".

dreusrequeza
dreusrequeza

Yes, I agree that as CIO (or as a leader as we say)you have to empower your people, give them opportunity to lead projects, support and back them up and so on... The question is when should these things be happening? At the start of the project? Or when the project is just an inch away from being pulled down to hell? This article has presented the situation where the CIO brought the issue onto herself. And at the last minute tries (or will probably try, as the article suggests) to pull the magic wand onto one of her staff because of the idea that the CIO should not be taking the heat and gives this opportunity (to be cooked alive by the steering) to one of her staff?!? "When the CIO is the face of the project to the steering committee she looses her ability to back up and support her people ON the steering committee. When the CIO is nothing more than the lead techie in the room that now has to step in and fess up for any and all IT mistakes as soon as they happen, then the CIO has no strategic influence or power to drive a meaningful agenda." If the article started with Martin as the one leading the project, as the one who made the mistake, as the one who will face the steering commitee... Then we can now look at the CIO how she will deal with this situation and backup/support Martin. But its not like that. One of my statements on my resignation letter given to an old company I used to work for "...I cannot report to somebody who cannot support me technically and functionally..." Why? It's common sense, the only reason why a CIO sits as CIO or a VP for Sales sits as VP for Sales without knowing the "nitty gritty" is beacause of either politics or something similar to it. "There are CIOs who get this and do things very differently and I have seen them achieve astounding success for IT, their teams and themselves. Very often they are CIOs who do not have a background in IT and therefore are completely reliant on the IT expertise of their people to succeed. This situation FORCES them to stay out of the nitty gritty of the project and instead focus on supporting their people, supervising the adherence to IT governance process and enhancing the relationship between IT and other functional areas."

Tony Hopkinson
Tony Hopkinson

of good leadership is persuading your people to hold the buck so the leader never gets left looking responsible..... So if a CIO who does this sets an example for their eople to follow, it was the cleaner's fault? Not being funny but I'm a tech because I like it and I'm good at it, not because I was too stupid to make it in management. Try again.

mafergus
mafergus

With a speech that explained, "...you are either in or out. You either get it or you don't...A company has to commit to SAP 100% or not at all..." We weren't 100% so we spent twice the money for Bolt-ons and other ways to maintain all of the systems that SAP was supposed to replace. I think Christene's organization never fully bough into SAP and you will never implement such a program without support at all levels. She needs to cut bait and determine which components are helping the organization and lose the rest.

drktech1
drktech1

Bringing up past success will actual just start to tee people off. People will want to know if you think your so good how come you really screwed this one up.

Tony Hopkinson
Tony Hopkinson

great absolutely not. After all, you are saying people are putting their own personal goals so far in davance of their professional ones, they look unprofessional.....

gechurch
gechurch

You are of course absolutely right. The first world are the lowly people actually doing the work. The second world are the management committee's. Businesses generally seem structured so that these people only hear the positive. No-one wants to bring bad news to their bosses. In the example given in the article, I dare say that if Christine (world 2) spent all of 5 minutes talking to a few people from world 1 before approving the project and it's add-ons, she wouldn't be in the position she is now in. Unfortunately some managers see their role as being "the important person that makes all the decisions". To my way of thinking, people in world 1 are in the best position to know what's going on. They have the expertise, they will actually be doing the work. There's nothing wrong with being the important person that makes the decisions, but talk to everyone involved and make an informed, fact-based decision. If Christine did do that, she wouldn't be in the position she is in now. I gather she hasn't learnt her lesson either. It sounds as though she is heading to this meeting without having talked to the people involved in the project. She thinks the project should be killed, but again doesn't seem to have done due diligence. There are many options others have already pointed out (can we drop certain parts, or do them in version 2. Has she checked the contract regarding those add-ons? Has she contacted the vendor and tried to renegotiate etc etc). I don't care what happens to Christine. Yeah, Martin may have some good advice that gets the project killed and makes Christine look great, but so what? Is that a good thing? Hell no... she continues to make poor decisions based off her ill-perspective. Good riddence if they sack her.

adrianhorod
adrianhorod

Make a deeper check and see that those people never reached the end of a project . They just moved on while the management was still excited with the opportunities

NotSoChiGuy
NotSoChiGuy

My take on this was that the SAP expansion was the project. I could be wrong, though. "I can't believe I let those guys at SAP talk me into adding a bunch of new modules onto this system." What I'd like to know is who initiated the contact. Was Christine reaching out to the SAP people because there was a clear business issue, or did they get her to a hosted event, and plant the idea into her head? I'd also be interested in reading whether or not due diligence was ever performed. Doesn't seem as though it was, from what is given.

rags721
rags721

I do agree with keeping the personal responsibility and professional responsibility separate. This gives us a perspective from which we can make tougher decisions. However I do not agree to switch the sides of the table. Either case it does not take the responsibility off your shoulder. The best way is to accept the responsibility and move on with cutting the losses. Rethink the whole strategy. Put the new stuff on hold. Start looking at ROI on the original scope and if it still makes sense, move ahead with the reduced scope. Hold the vendor responsible for misleading. Reset the expectations of the steering committee and split the deliverables in a meaningful manner.

Mark A. Lewis
Mark A. Lewis

That was very well said. Complete agreement here.

biancaluna
biancaluna

Which is why I have been very quiet in the past 6 months. The CIO micromanaged all projects within the program, I was one of the PMs on a critical component. CIO was an acquaintance of mine and she asked me to help out and conduct a health check in the process. Patient is half dead, doctor, let's perform some surgery. CIO took that very personally and that is when the problems that could have been resolved became festering wounds. Yes, she was responsible for the failure, and she is still beating that dead horse. I agree with Tony, isn't it the CIOs job to articulate and champion the vision? Isn't it the CIOs job to apply some level of leadership and prudent management? Seems to me that many CIOs are in the game for the service of self, and that is where ego gets in the way and burns the house down. I got out before she could stake me to the ground, and made damn sure I kept records. The last PM on the program resigned on Thursday, she has nothing left. But is blaming everyone but her own lack of judgment, she did not want to listen to professionals. Fess up, take responsibility and sauve qui peut. Keep some distance, delegate to professionals, ultimately, the cio needs to manage to the corporate plans and strategies, let professionals do the program management. That is still not a recipe for assured success but it might avoid blinkered CIOs with more ambition than skill and common sense driving Titanic straight to the iceberg.

dwerhart
dwerhart

I have to tell you that sometimes projects fail and fail miserably - despite our best efforts we sometimes make mistakes. Leadership is not always measured in how successful we are, rather how we deal with mistakes and failures. Show me an I.T. leader who has NEVER had a failed project or a project that failed because someone made a mistake and I will show you someone who either avoids projects, or waits until the entire landscape of similar projects in the same scope have been tried and ironed out. In other words ? they no longer keep a competitive edge for their organizations. How a leader deals with success and failure says a great deal about them. Should they take all of the blame? If a vendor sells an organization a solution, and the solution requires a major IT project and the CIO for that organization champions the project based on the information they have, then the project subsequently fails, should the CIO step down? Perhaps, but I will pose this question to you, if we lost everything when we took a risk, would we ever take a risk? If a CIO kills a ?blood sucking project? before it drains the coffers further, isn?t that a step toward good leadership? Should the CIO ?fake it? and cost the organization another 2 million dollars without a comprehensive TCO/ROI scenario? Should they put on their whipping boy attitude, accept all the blame and consequences and not try to figure out/learn how the project failed? I think a good leader would kill the project ? provided they cannot realize a demonstrable return or gain for the organization. In accounting the term is ?sunk cost?. It is a major tripwire in any organization. Having a project go over budget, beyond scope, beyond timelines will happen to anyone leading projects ? eventually. Making the decision to kill a project is sometimes a mark of good leadership. Analyzing the TRUE causes of failure and communicating them is in NO WAY shifting blame. Armchair quarterbacks will always be out there to deride great leaders. Generally those who are quick to point a finger are the ones who will be unable to deal with failure in a proper leadership role. The bigger question is also this - a comprehensive and unbiased review of the project will reveal what happened to create the failure in the first place. To take blame for something that is not your fault is erroneous as well and it helps NO ONE. To rightly disect the project and analyze what went wrong where is in no way "foisting it off on some poor twonk", rather it is an attempt to learn from mistakes and avoid them in future projects. It is - in all likelihood - not some poor twonk's fault but a combination of events foreseen and unforeseen that contribute to derail a project. Taking responsibility is not "accepting blame" it is time that good I.T. leaders learn TRUE humility, figure out how to correct and learn from issues. Having your staff "man up" if they are part of the problem is not a bad thing either. Clean it up, dust it off, take notes, and dive back in to another project... Leadership...

mafergus
mafergus

Actually, he'd be getting ready for his "big opportunity" to make that presentation for the board, which of course will forever tie him to the project and allow the CIO to "do the board a favor"...

Ed Woychowsky
Ed Woychowsky

Even old squid-face himself wouldn't touch this turkey. Perhaps changing your name and moving to another country could help.

dwerhart
dwerhart

I would like to see the remainder of the article before I cast stones. What does it say about Martin's response, how the CIO moves forward. A blanket assumption that the CIO will "pass the buck" is a bit premature at this point of the article. I will hold off commenting on this until I see the conclusion.

AppDevGuyFromTX-21702053807677063493239650930425
AppDevGuyFromTX-21702053807677063493239650930425

From the title, I was expecting advice on how to diplomatically shoot down ill-conceived projects. A more descriptive title would be "Stay a live chicken by never putting your bacon on the line". In my experience, NO project ever comes to fruition unless one or more highly-capable people put their bacon on the line by taking ownership. If no one at the top is accountable for the success or failure of the project, it goes nowhere. So you recommend instead of taking her lumps, Christine become a useless bureaucrat who adds no value and never has to actually deliver anything? Boy, do we need more of those in the IT world!

wanharris
wanharris

You're right bro. Your business will get bankrupt for blaming on others. The best defence, is a good offence. And that is by telling the truth, nothing but a truth, only the truth!

dreusrequeza
dreusrequeza

You can catch a fish thru its mouth... More talk, More mistakes, Less talk, Less mistakes. Why bring up the past? That is an obvious move to try and cover up, which will be no doubt ineffective and surely backfire straight to your face. Go with the facts at hand.

Tony Hopkinson
Tony Hopkinson

Put far more credence in the 'advice', of Vendors, External consultants and Gartner style interest groups, instead of their people. If a vendor comes up to me and says "Buy this and it will solve all your problems" A simple word substitution ( swap your for my), reveals some potential difficulties with the veracity of this statement.

Tony Hopkinson
Tony Hopkinson

First this person is the CIO, and the angst is it's her project that's going to be killed. She believes she will lose a lot by ding the right thing, and apparently seems more concerned about that. The other muppet describing the situation, thinks she should have lined up a scapegoat in case it failed before she started. As for objective reviews of what went wrong. "Well you went to dinner with some vendors, had one glass of red too many and signed us up for something no one else thought would work" Accepting responsibility starts at the top, and will only happen if the consequences aren't too extreme. Indeed I'd take a wild guess that in this situation some one has been hiding under their desk, hoping a technical twonk would wave their wand and rescue it....

gechurch
gechurch

I agree with what you are saying. I think others are commenting on the advice this article provides about what Christine should have done... which was effectively to play devil's advocate, and not to take on any responsibility for it, instead pushing that burden to the vendor (I'm ok with this advise) and her subordinates (this is the suspect advice).

ayaz.haniffa
ayaz.haniffa

need to own up... Whatever happened to due diligence?

Tony Hopkinson
Tony Hopkinson

One was a review of inventory management and puchasing package. We were told that because of political considerations no matter what we found it was going in anyway.... We still did an extensive review, it was cya time. Came in handy when the wheels came off repeatedly.

mafergus
mafergus

I was involved in a project where we were directed to choose an significantly inferior product as part of a major initiative, because it was believed that crap with support was better then open source without. It's not fun taking a bullett when you saw it coming and fought like the dickens to prevent it.

Editor's Picks