BIZPEOPLE 4 continued from page 10 that I’ve seen practically every different type of dispute stage. My standard sell is a 12-week exercise. At the end of 12 weeks, we’ll have either cured or killed the project. And I exit, with the project either back on track or killed. Sometimes when I exit, I’m sending in lawyers to deal with termination [of the project]. But more often than not, I’m handing it back to the project managers, and am retained as the “program conscience.” CIO.com: With large enterprise software projects, what patterns do people and teams fall into? Coyne: When the project starts, the [technology-buying] organization sets out clear outcomes. You see strategiclooking documents on anticipated success: a percentage increase in the way we do this type of process; greater efficiency here, greater visibility of doing business there; faster this, that and the other thing. That’s a very positive stage. But then what generally happens is that detail-oriented techies get involved and business objectives get boiled down to technical function. The danger is that people end up contracting or creating an agreement to deliver technical function, and that’s how the “success” of the project is measured: on the amount of technical functions delivered. Often, there’s a loss of vision into why the project was started in the first place. So the business concept we were trying to achieve—greater visibility to the directors or executives, or new business processes—is often lost, and that’s where a project starts to fail. CIO.com: That’s where you come in? Coyne: You must remind the project team what they are aiming for. In disputes, the customer wants to protect the project’s objectives. But often the supplier says: “We contracted to deliver you a module that delivers XYZ functionality, and we delivered that, therefore we’ve discharged our contractual obligations.” But the customer will often say: “Yes, but this CRM system that you delivered doesn’t deliver on those [original] high-level objectives.” But [the supplier] didn’t contract for these high-level objectives; they’ve just delivered a CRM system with these modules in it. That’s the disconnect. I’ve got to demonstrate credibility, and the way to do that is to show them that I’m vehemently independent CIO.com: Is there a way to fix that? Coyne: When there’s a disagreement about the deliverables, I have a process I call “alignment of objectives”: supplier and customer go through a matrix of strategic, operational and functional objectives. The customer is responsible for the strategic objective, there’s a partnership [of all involved] on operational objectives, and the technology vendor is responsible for functional objectives. This process forces people to focus on the reasons they entered into the project. It generally gets universal buy-in because [by this point] the tech vendor sees they will never going get the project delivered unless they understand what the customer is trying to achieve. CIO.com: How do you deal with the emotional baggage of these expensive, career-threatening project failures? Coyne: Customers always say that the vendor—prior to signing the contract— told them they understood the project, understood the business, have implemented similar systems in the past, and described the great ROIs other companies have seen. Pre-sale, they’ll also tell customers they’ll get “the A team’ [of tech-workers]. But then once the contract is signed, the customer gets the B team, because the A team went off to sell the next system. Customers get emotional because they must define how they want the system to look. They always say: “The vendor keeps saying to me: ‘You need to specify how you want this to look and work; spec it out for me’. Customers are frustrated by that, because the customers understand their business processes, but they don’t necessarily understand what the [vendor’s] technology can do. And that’s why they contracted with these specialist vendors! They didn’t expect to have to spec it out—they expected the vendors to guide them through the process and meet them halfway. So my job is to put the customer back in his comfort zone. CIO.com: How are you different from a project-management turnaround specialists at the big consultancies? Coyne: Those people are usually new project managers who come in and try to understand the governance processes that have been used by the project. They’ll try to tweak the project and it make operate better. But they seldom try to realign the project to its original objectives. If the project is going in the wrong direction, doing it better means you head in the wrong direction quicker or more efficiently. You’ve got to ask: Why did we ever start this project? 3 12 <strong>Computer</strong>world <strong>Hong</strong> <strong>Kong</strong> Nov 2009 www.cw.com.hk
www.cw.com.hk .com.h mhk Nov 2009 <strong>Computer</strong>world orl <strong>Hong</strong> <strong>Kong</strong> 13
Change language