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. [For more on this topic, see Project Management: The 14 Most Common Mistakes IT Departments Make.]
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.