As an Oregon taxpayer, I was appalled at the millions lost when the Cover Oregon website was scrapped.
At the same time, as a software systems analyst who has worked on numerous commercial websites that never saw the light of day, I had to admit to myself: "Been there, done that."
Most readers know that bureaucratic infighting, mismanagement and unrealistic schedules contributed to Cover Oregon's failure. What the public may not know is that a lot of software projects fail, even in the best of environments.
When no taxpayer money is involved, we don't usually hear about it. But it is a shameful secret within the information technology world.
A senior information technology executive at one of the nation's largest banks writes frankly about IT failure for the business technology website Information Week, but he uses the pseudonym "Coverlet Meshing" to hide his true identity. Meshing reports that "the failure rate for technology projects is anywhere from 37 percent to 75 percent."
I recognize Cover Oregon's death spiral as a story that I have experienced on my own doomed projects. Not all failed projects fail as publicly and spectacularly as Cover Oregon, but the pitfalls and missteps in the saga all seem familiar to me.
I believe it started with a trap common to big projects in all human domains: "The Planning Fallacy," or the tendency for people and organizations to underestimate the complexity of the requirements and how long it will take to build the system.
It happens when people take on any ambitious task, be it building a jet fighter, a new school curriculum or a backyard irrigation system. It's always harder and takes longer than you think at first.
I believe the next misstep was the design choice to use Oracle's Siebel Customer Relationship Management System as the heart of the system, even after insiders raised concerns that the product was proving to be overwhelmed by the task.
There is nothing wrong with Siebel per se. It has been implemented successfully by thousands of organizations around the world. But as the requirements for Cover Oregon grew in complexity, team members and consultants began to see that Siebel would not scale well in the direction that the requirements were moving.
According to The (Portland) Oregonian, as early as May 2013, "A Cover Oregon technologist raised dozens of 'critical' problems with the Siebel Customer Relationship Management System at the heart of the project devised by Oracle."
Later, as IT oversight analysts scrambled to get the project in hand, analyst Bob Commings said he was "alarmed by the thousands of lines of custom software code, suggesting the Oracle product simply wasn't 'very well tailored to what Cover Oregon and OHA (the Oregon Health Authority) wanted to build.'"
"Thousands of lines of custom software code": That was the critical juncture. Perhaps there was time to go back and fix the underlying design at that point. Instead, the warnings were ignored and the team's members tried to frantically code their way out of a foundational design flaw.
When members of a team write thousands of lines of code to work around a design flaw, they create what software management guru Robert Martin calls a "software mess," adding, "I have seen products ruined and companies destroyed by software messes."
For a more concrete analogy of this story, imagine a retired couple decides that a simple mobile home will meet their needs. They like to sit outside in the afternoon, so they add a patio and a birdbath. So far, so good. Then comes an unexpected requirement: Their daughter is divorced, and they need two more bedrooms for her and the grandkids. They wonder if somehow they can add a second story to the mobile home by extending posts up from the aluminum walls.
If they tried this, they'd probably see soon it wouldn't work at all. But if they continued to tack on more and more reinforcements to work around the weakness of the foundation, they'd end up with an ugly mess. Sooner or later, they'd realize the structure of the mobile home wouldn't support a second story, and that it would be best to start over with a fresh design.
I suspect it was the same with the Cover Oregon software mess. At one point, you just can't code your way out of it; you need a fresh approach.
In the end, the decision to scrap Cover Oregon was galling - but it was probably the rational thing to do.
At the same time, as a software systems analyst who has worked on numerous commercial websites that never saw the light of day, I had to admit to myself: "Been there, done that."
Most readers know that bureaucratic infighting, mismanagement and unrealistic schedules contributed to Cover Oregon's failure. What the public may not know is that a lot of software projects fail, even in the best of environments.
When no taxpayer money is involved, we don't usually hear about it. But it is a shameful secret within the information technology world.
A senior information technology executive at one of the nation's largest banks writes frankly about IT failure for the business technology website Information Week, but he uses the pseudonym "Coverlet Meshing" to hide his true identity. Meshing reports that "the failure rate for technology projects is anywhere from 37 percent to 75 percent."
I recognize Cover Oregon's death spiral as a story that I have experienced on my own doomed projects. Not all failed projects fail as publicly and spectacularly as Cover Oregon, but the pitfalls and missteps in the saga all seem familiar to me.
I believe it started with a trap common to big projects in all human domains: "The Planning Fallacy," or the tendency for people and organizations to underestimate the complexity of the requirements and how long it will take to build the system.
It happens when people take on any ambitious task, be it building a jet fighter, a new school curriculum or a backyard irrigation system. It's always harder and takes longer than you think at first.
I believe the next misstep was the design choice to use Oracle's Siebel Customer Relationship Management System as the heart of the system, even after insiders raised concerns that the product was proving to be overwhelmed by the task.
There is nothing wrong with Siebel per se. It has been implemented successfully by thousands of organizations around the world. But as the requirements for Cover Oregon grew in complexity, team members and consultants began to see that Siebel would not scale well in the direction that the requirements were moving.
According to The (Portland) Oregonian, as early as May 2013, "A Cover Oregon technologist raised dozens of 'critical' problems with the Siebel Customer Relationship Management System at the heart of the project devised by Oracle."
Later, as IT oversight analysts scrambled to get the project in hand, analyst Bob Commings said he was "alarmed by the thousands of lines of custom software code, suggesting the Oracle product simply wasn't 'very well tailored to what Cover Oregon and OHA (the Oregon Health Authority) wanted to build.'"
"Thousands of lines of custom software code": That was the critical juncture. Perhaps there was time to go back and fix the underlying design at that point. Instead, the warnings were ignored and the team's members tried to frantically code their way out of a foundational design flaw.
When members of a team write thousands of lines of code to work around a design flaw, they create what software management guru Robert Martin calls a "software mess," adding, "I have seen products ruined and companies destroyed by software messes."
For a more concrete analogy of this story, imagine a retired couple decides that a simple mobile home will meet their needs. They like to sit outside in the afternoon, so they add a patio and a birdbath. So far, so good. Then comes an unexpected requirement: Their daughter is divorced, and they need two more bedrooms for her and the grandkids. They wonder if somehow they can add a second story to the mobile home by extending posts up from the aluminum walls.
If they tried this, they'd probably see soon it wouldn't work at all. But if they continued to tack on more and more reinforcements to work around the weakness of the foundation, they'd end up with an ugly mess. Sooner or later, they'd realize the structure of the mobile home wouldn't support a second story, and that it would be best to start over with a fresh design.
I suspect it was the same with the Cover Oregon software mess. At one point, you just can't code your way out of it; you need a fresh approach.
In the end, the decision to scrap Cover Oregon was galling - but it was probably the rational thing to do.