Walsh heard about it from a friend. The Cover Oregon project would be a one-stop health coverage shopping site that would allow consumers to compare health plans, qualify for lucrative tax credits and enroll in a single sitting. The federal government was supplying Oregon with tens of millions in extra funding to serve as a model for other states.

Excited by the vision, Walsh applied and went to work on it in April 2012 as a consultant.

The warning signs were immediately apparent, Walsh says. He moved into a cubicle with the state’s IT team, in a Salem office building.

Rather than sitting among the workers, top management was rarely to be seen — which Walsh characterizes as “very abnormal … There were a lot of disputes about how we should be doing things that nobody stepped in and took charge of.”

The project’s top managers employed a mishmash of project development techniques, adopting multiple methods over time, but never instituting the training or changes needed to make them work, he says.

Walsh came to realize the dysfunction was mirrored on the Oracle side, where workers for the state’s chief contractor were divided into fiefdoms reporting to different managers. In fact, Walsh’s Oracle counterparts sometimes warned him to be skeptical of the company’s work in other parts of the project, he says.

His job was to oversee how the project tracked financial transactions, such as payments to insurance agents for helping consumers.

But he and his Oracle counterparts were repeatedly rebuffed in 2012 when they sought information from other parts of Oracle that they considered crucial to the project’s success, such as how massive quantities of data would fit together under the project’s design, he says.

The data design would be ready in two weeks, they heard over and over.

Walsh began to have his doubts. “You tell yourself, ‘They can’t be that bad … I’m sure they’ve got something.’ ”

After a while, Walsh pursued a separate data design for his portion of the project to ensure his team was not held up. He credits that decision for his team’s success, as the financial side of Cover Oregon worked fine and was completed on time.

In contrast, Walsh still recalls the shock his team felt in July 2013 upon seeing the design for how enrollment would work for the project. A colleague’s muttered reaction: “Well, that’s not going to work.”

Walsh says it appeared that Oracle managers felt they didn’t need to do a ground-up design, that they were just modifying existing off-the-shelf Oracle software.

Walsh was surprised to hear from Oracle in fall 2012 that the health insurance system its staff envisioned had no capacity to process mid-year changes in a family’s health policy, premiums or tax credits after they enrolled.

Such changes — due to a birth, death, divorce or a wage-earner losing their job — are common, and on multiple occasions Walsh urged Oracle to accommodate changes in its design. The response? We’ll get to it later.

Not until September 2013, the month before the project was supposed to go live, did Walsh and his team learn that Oracle’s design for the health insurance project still did not allow changes to a family’s policy or circumstances. This meant Cover Oregon would not be able to share data effectively with the insurance carriers it worked with — a basic problem that caused ripple effects throughout the project’s workings.

This, Walsh believes, was the “fatal flaw” of Cover Oregon, and why the exchange had to be scrapped. Fixing the problem would require major changes at great cost. And the project’s budget was already largely expended by the time the problem became clear.

Walsh’s diagnosis mirrors congressional testimony given by Alex Pettit, the state’s top IT manager, who was brought in to try and rescue the project in early 2014, only to realize it was impossible due to the “fundamental design error” concerning mid-year changes in a family’s policy or circumstance.

“The whole thing was going to have to be rewritten … It was truly unbelievable that it would ever be designed that way,” Pettit told congressional investigators, adding that when he complained to Oracle about its design, the response was, “Well, it wasn’t in the specification.”

Pettit’s retort: “Well, it didn’t need to be in the specification. You knew you had to keep track of changes to records, and the system wouldn’t keep track of it.”

Walsh echoes Pettit, that because the project’s programming was in Oracle’s hands, the technical design was arguably the company’s responsibility.

But Walsh says the state bears responsibility for other problems, including delays and wasteful spending.

For instance, the state spent months and millions of dollars trying to perfect a new type of interface to shift data between two components of the project. Walsh urged the use of a standard Oracle product instead. In the end, when an Oracle analyst confirmed to Cover Oregon managers that Walsh’s idea would work, a top official asked how long it would take to set up the solution.

“What time is it?” responded the analyst, and the fix was set up later that day, Walsh recalls.

For all the criticisms of Cover Oregon, Walsh says parts of the system worked well. And the non-technical program side of things, such as the variety of plans offered and number of insurers participating, was a great success.

“It wasn’t that the whole thing failed,” Walsh says, adding that the project’s insurance design “was one of the best in the country.”

But while a state consultant’s report on Cover Oregon highlighted mismanagement, and Pettit, the top state IT manager, has instituted reforms, Walsh says he’s not sure either addresses some of the biggest management weaknesses he’s seen in Oregon when it comes to large IT projects.

Walsh has watched several Oregon projects play out, and his account of a larger problem of management culture echoes other consultants who spoke privately with the Portland Tribune.

Oregon features a top-down management style, in contrast with other states, says Walsh, who has studied management. Successful projects, however, feature communication flowing up and down the command chain. On Cover Oregon, this management style led to an early focus on schedule rather than design. Later, management obsessed on the website’s appearance while ignoring the details of how it would work.

Another problem that seems endemic to Oregon IT projects is cronyism, rather than hiring the best-qualified staff, Walsh says.

While Oregon officials like to complain the salaries allowed by the state aren’t large enough to afford top IT management talent, Walsh says the real problem is Oregon doesn’t use top consulting talent the way it should. And while the people running Cover Oregon had IT experience, they lacked a record of success in large IT project development.

Because of the cronyism, accountability suffered. “The ‘in’ people seemed to have more leeway,” Walsh says.

The weakness in management led to unnecessary delays and inefficiencies, and likely contributed to the state’s failure to challenge Oracle on key issues, Walsh says. And when problems came up, the state did not replace non-performing managers with better ones.

“They hire people they know,” Walsh says, “And then, when things don’t go well, they hire more people they know.”