Public and private sectors have diverging views why IT projects go off rails

Public sector IT managers and consultants who work on government projects may disagree on a lot of issues. Some of those disagreements generate more publicity than others.But there’s one issue they appear united on: When IT projects stray off the straight and narrow, the fault invariably can be traced back to a lack of communication, four participants recently agreed at a GTEC Week panel discussion.
Sometimes, as Dan Perley, co-owner of an Ottawa-based IT consulting firm, illustrated, that lack of communication can have serious consequences. Perley, who was a director at Transport Canada for two and a half years, says one of the most embarrassing and frustrating experiences he has ever had in his IT career was when he failed to spend $110,000 out of his $10 million budget. 
“I didn’t spend it because the consultant I’d hired a number of months (before) to do a project died, and he didn’t have the decency to tell anybody he’d died,” he said. “We discovered eight days before we got into the fiscal year that there were no deliverables. The reality was it was incumbent upon us and upon him to communicate. We thought he’d just go away and do it and come back eight months later with a report.”
Communication essential
Norman Carr, a senior vice-president at Ajilon Consulting, said he, too, has seen his fair share of horror stories on government IT projects. But he’s not optimistic about improvements. “At the end of the day, if I look at most of the projects I’ve seen going off the rails it typically comes down to communication — one person not communicating well with another, and I don’t know how to resolve that,” he said. 
John Davis, a senior partner at Ottawa-based Partnering & Procurement Inc., agreed. “In a lot of the projects we deal with in information management/information technology (IM/IT), the ‘T’ is relatively straightforward; we know how to deal with that,” he said. “The biggest problem we have is the ‘M’ (management) part.”
According to Bill Pascal, chief technology officer for the Canadian Medical Association, while failure to communicate can quickly derail any IT project, government departments and agencies have a greater chance of a successful outcome if they are working with service providers who are willing to share not just in the rewards but also the risks.
“With the CMA or when I was with the federal government and I was trying to strike (a deal) with a vendor, basically I was trying to set up a partnership, and I don’t use that term loosely,” he said.
What’s a parternship?
For Pascal, a partnership is a relationship built around trust, respect, risk-sharing and fairness, with clear accountabilities and responsibilities. But in his experience, public sector IT managers are often constrained by rules that don’t allow them to develop contracts that reflect the qualities of a true partnership. “One of the things we’ve found when we look at P3s (public-private partnerships) or procurement of services and solutions on major programs is partnerships are between people; contracts are between entities,” he said. “I cannot buy you as a procurement specialist working with Public Works and the provincial governments a relationship or a partner. I can identify someone who can lead to a partnering type of relationship, but I can’t buy you a relationship.” 
Davis added that many of the project failures that make the headlines generally are the result of department heads who decree IT projects to meet policy mandates rather than operational imperatives.
“We have issues where there is a policy directive to do something but there’s nowhere on God’s green earth you can actually implement it in the time frames laid out,” he said. As a result, a lot of major projects are doomed to failure: stakeholders start to see it as something they have to live with and executive support also drops off.
The solution, he offered, is to simply lower expectations.
“Why do we keep insisting on critical success factors like consistent, committed executive support when everybody knows you can’t get it?”
The other solution, said Carr, is to scrap the long-standing practice of using fixed-price contracts.
“The nature of a fixed price deliverable contract immediately puts you in an adversarial relationship. It has to,” he said.
Carr added he tries to steer his clients toward arrangements that accommodate the huge number of changes and miscommunications that inevitably arise in a project. “Most often when things fail the customer says one thing and believes they have communicated that to the vendor, or the integrator hears another thing and thinks that’s exactly what they asked for,” he said. “Then they get upset when the customer gets upset because they didn’t get what they wanted. It’s a very difficult relationship issue.”
Change requests inevitable
Carr gave the example of a two-and-a-half year project his firm recently worked on for Export Development Canada.
“It wasn’t a fixed price relationship, it was an integrated management team that had management’s commitment,” he said.
And although management thought it had the requirements nailed down after taking 18 months to spec it out, there were still 2,500 change requests from the beginning to the end of the $25 million project.
“If we had done this on a fixed price basis we would have lost our shirts.”
Perley also noted that the Canadian Air Force subjected the Avro Arrow project to 27,000 change requests.
“So start out with what you want, don’t make changes unless you have to, give the consultants a longer leash, but put accountabilities in there as well,” he advised. “Reward extra performance with extra carrots however you can.”
This is the real world
That’s a nice idea, but it doesn’t work in the real world, argued Pascal. “How many of you are involved in project delivery?” he asked audience members. “How many of you actually defined your requirements enough that you never needed to make any changes?”
Pascal said his experience working with doctors illustrates that problem perfectly. Doctors have difficulty translating the delivery of care into business processes. They can’t explain how they work to a technical person since they are not trained to think that way, so it’s challenging to figure out the IT environment they need.
“You might be able to define 80 per cent of the functionality, but when you get into it there’s some tweaking,” he said. “I think you need you need to have the rules set out where there’s a degree of flexibility. Part of it is expectation of where you want to go, and part of it is you’re allowed some degree of flexibility in the contract so you’re allowed to play with some of the functional needs. It is going to change some of the dimensions and I think there are creative ways to build contracts with some flexibility so we get out of the blame game.
“You don’t blame somebody because they told you some wrong stuff or in the journey you discovered together there is some other stuff you should have thought of.” 
But the need for flexibility goes both ways, said Perley.
Too often the IT consultant will spend enormous amounts of time and money to prepare for an RFP only to find out the project has been cancelled, he said.
“I think maybe we need to have a meter where the person that is issuing the RFP says the funding is coming from here, the internal risk of this project being cancelled is X, the risk of the organization is Y and the risk of my leaving before the project is finished is Z; but the reality is unless we’ve got really good intel in an organization or got people in there, maybe not spies, but people are who are very, very aware, people in the private sector don’t get that sense of it. You can’t legislate good faith in a contract, and you absolutely have got to have agreement on both sides, and then you’ve got to communicate.”
It’s really up to the CIO to make sure that communication is happening, noted Pascal.
“A good CIO is a marriage broker, not a techie,” he said. “A CIO manages personalities and expectations and tries to bring those things together, and in fact a public sector CIO should be spending more time with senior management to get them on side and figure out what’s going on and keep them out of the hair of the operations people. Where I’ve seen projects go off the rails is when the CIO has said, ‘yes we can do it,’ knowing damn well it will never get there because it’s not a tech issue, it’s a policy issue.”