Jason Coyne describes his unusual job in many ways: Marriage counselor. The Equalizer. Relationship guru. Project conscience. Resolution manager. The Fixer.
To those groups toiling away on your garden-variety technology implementation-the vendor, the customer, the integrator-Coyne’s arrival on-site usually means one thing: A big tech project is in trouble. And Coyne’s job as an objective third party is to either “kill or cure” those projects that have gone awry. (Coyne is sort of like a U.K. version of Winston Wolf, Harvey Keitel’s industrious character from Pulp Fiction: “I’m Winston Wolf. I solve problems.”)
Coyne, who’s managing partner at the Evolution Project Consulting firm, claims to have worked on more than 500 different projects in the U.K. and abroad since the 1990s. “Not all disputes,” Coyne adds, “but most of them have been.” (Some companies have hired to come in at the beginning of a large project to prevent a disaster.)
CIO.com Senior Editor spoke with Coyne about the ill-fated patterns and emotional traps that most tech implementation teams fall prey to, how he “sells” himself to his customers, and why companies often forget about a project’s original goals during implementations.
Related stories:
Smart project management helps Canadian firms save time, money, labour
Five free apps that make project management a breeze
An IT project auditor could help spot problems before you need a task force
CIO.com: How do you describe your job to someone at, say, a cocktail party?
Jason Coyne: I describe it as “marriage guidance for technology agreements.” So just as different, diverse people come to together in a marriage, different and diverse organizations come together to form a project. And when there’s fallout, they need somebody independent to help mediate and resolve the disputes.
There’s no real rocket science in what I do. I just help people understand why they’re in this relationship, this agreement. Usually, they just lose sight of what their goals are; in a marriage, people can lose site of that: What they’re in the relationship for. I just really bring that back to the forefront of the attention, and they start focusing on the common goals.
CIO.com: Who typically hires you?
Coyne: Generally it’s the purchasing party I’m instructed by; sometimes the technology vendor or systems integrator. But [my services can be hired] for anything to do with technology and a commercial dispute, if there’s a contract and a legal agreement in place.
CIO.com: How did you get into this?
Coyne: I originally was an out-and-out techie. I started as a fourth-generation language programmer. I created business control software, accounting and manufacturing software back in the late 1980s. I didn’t really enjoy programming, but I saw how things got created. And I actually implemented a number of these systems that I helped develop.
In the early ’90s, one of the systems that I’d helped build ended up getting into dispute. One of the companies found me and [asked me] to give evidence about the way the software was put together in first place, and I ended up giving evidence in a trial of the software that I helped write.
Since then, people have just come to me for my opinion on various types of agreements that have to do with technology, over 500 different projects since the 1990s.
CIO.com: What is it that the companies who contact you are looking for?
Coyne: The more visionary customers understand that if I’ve been through that number of disputes, then the chances are good that I’m going to understand how to steer them through the murky waters of their technology implementation and how to avoid [failure] in the future.
I’m working with some pretty big global companies-both [technology] suppliers and customers-on dispute avoidance, just to be “the voice of reason” on a monthly or six-week basis: Come in and have a look at where the project is going and see if I can tease it back on track. Almost like a “project conscience.” It helps people see what’s important to the project, because project teams invariably get too close and involved in the details, and they lose sight of the direction of where the project is actually going.
CIO.com: Do you usually get a warm or frosty reception?
Coyne: There’s often suspicion, because historically I’ve been the customers’ champion, and in court cases, I’ve generally been acting as counsel to the customer against the big, bad technology supplier that’s let them down.
So often it’s a very frosty reception from the computer vendors. When I get wheeled in front of these global systems-integration players I hear: “Oh, are we in a dispute? I thought this guy only got involved when the relationship is over and we’re on our way to court.”
CIO.com: How do you sell yourself to all these groups of people involved?
Coyne: I’ve got to demonstrate credibility. The way to do that is to show them that I’m vehemently independent. And whilst I might be instructed by the purchasing organization-the end-user customer-or when I might be instructed by the technology provider-the supplier in relationship-if it’s the case that either of the parties has failed to discharge their obligations to the agreement (because it’s generally not all one-sided), then I will be constructively critical of either party.
The way that I convince people to contract with me is to explain to them that I’ve seen practically every different type of dispute stage. And if for too long a long time a customer has been considering whether they should kill or cure a project, then it seems that they’ve generally not known how to cure it. I’m the only option available to them.
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. It’s sometimes the case that when I’m exiting, I’m bringing the lawyers in to deal with termination. But more often than not, I’m handing it back to the project managers, and I carry on being retained as this “program conscience.”
CIO.com: With large enterprise software projects, are there patterns that the people and teams fall into?
Coyne: There are very clear patterns. When the project starts, the [technology-]buying organization sets out clear outcomes that they wish to achieve. You generally see some strategic-looking documents about what a successful project will be: 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 the low-level techies get invovled-low, meaning detailed rather than skilled. At that point these business objectives get boiled down into technical functions. And while I accept that that has got to happen, the danger is that people end up contracting or creating an agreement to deliver technical function. Because when the project then starts at implementation phase, then the success of the project is generally measured on the amount of technical functions that are delivered: We’re talking at a very technical level here and the complete focus is on technical function. And generally at this point, there is a loss of vision into why the project was started in the first place.
So the business concept that we were trying to give-greater visibility to the directors or executives, or the 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 then have to get the attention of the various members of the project team and remind them about what they should be aiming for. In disputes, the customer wants to protect the project’s objectives. But generally the supplier will be saying: “No, we contracted to deliver you a module that delivers XYZ functionality, and we delivered that. and 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 they haven’t contracted for these high-level objectives; they’ve just delivered a CRM system with these modules in it. That’s the disconnect.
CIO.com: Is there a way to fix that, or keep it always at the top of the daily discussions?
Coyne: When there’s a disagreement about what should have been delivered, I will go through a process of what I call “alignment of objectives.” I get the supplier and customer to go through a matrix of strategic, operational and functional objectives. I generally say that the customer is responsible for the strategic objectives; there’s a partnership [of all those involved] when we talk about operational objectives; and it’s the technology vendor that becomes responsible for functional objectives.
It gets people focused on the reasons they’ve entered into the project. It generally gets universal buy-in because the technology vendor [by this point] can see that they are never going to 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 big, expensive and career-threatening project failures?
Coyne: The customer will always tell you that the vendor, prior to signing the contract, was telling them how much of an understanding they had of the project, how they understood the business, how they have implemented similar systems in the past, and the ROIs that other companies have seen. They’ll also say that, pre-sales, they saw some great people shipped in by the vendor. The A team. But then once the contract was signed, they got the B team. The A team went off to sell the next system.
What also gets the customers emotional is the processes of having to define how they wanted the solution to look. The customer will 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.” And the customers are very frustrated by that, because the customers understand their business processes, they understand their business. But they don’t necessarily understand what a technology is capable of. 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, to meet them half way. So my job is to put the customer back in his comfort zone.
CIO.com: How are you different than a project-management turnaround specialists at the big consultancies?
Coyne: They are just new project managers that come in. What generally happens is that a new project manager will come in and try to understand the governance processes that have been used by the project. He’ll generally try to tweak that and operate it better.
But the missing link is realigning the project back to its objectives again. Because if the project is going in the wrong direction, doing it better just means that you’ll get to the wrong direction quicker or more efficiently. You don’t get to the successful project. You’ve got to reestablish your eyes on the outcomes of the project. Why did we ever start this project?
When somebody signed off on this business case, what did we tell them we were going to deliver because it certainly wasn’t a CRM system, because nobody would have signed off on a £5 million CRM system. What they would have signed off on is a £5 million [mechanism to achieve] better visibility into who buys products from us or increase the company’s revenue stream in year two.
CIO.com: Have any of your customers or adversaries ever given you a nickname?
Coyne: Somebody was saying once that [my role] is like the fixer, because you need someone to fix these projects. Some customers have said: It’s like the equalizer, because as a customer we can’t really compete with the technical knowledge that the vendor has.
Do you Tweet? Follow me on Twitter @twailgum. Follow everything from CIO.com on Twitter @CIOonline.
Source: CIO