Requirements Failures for Major BPM Initiatives

Texas hasn’t had much luck lately with state-sponsored software projects. In some cases, working software can be turned off if it was found that procurement processes were undermined. In a case recently coming to light, Texas is doubling down on software that doesn’t work – but we can all rest assured that they followed all the purchasing P’s and Q’s. Lesson learned – follow the procurement rules. Such is the world of politics and software deployments. This OAG project with the State of Texas is near and dear to my heart for a few reasons:

It is right here at home in Austin, Texas

Our taxpayer money is being spent on this project

Child support processes are a big deal. They should be done right. Improving them is a great cause and mission.

This is a business process management project at its heart, or should be. Unfortunately it was cast as a database project. (sigh)

Another “root cause” was likely the requirements produced from an earlier phase. Many said the requirements blueprint was to blame. $46 million was spent to produce it over 3 years. And I have to say, without having read a word of it, I’m sure that it was a waste of the paper it was printed on by the time it was done. I and the companies I’ve worked for have done 100’s of successful software projects, if not thousands. And none of them spent even one tenth of the amount of money the Attorney General’s office spent on requirements.

Anyone in the software business, truly, would tell you that by the time 3 years are up, your requirements are out of date, at best. Out of date is another way of saying, “wrong”. Anyone in the software consulting business worth their salt would say the same thing. In the BPM world, every project BP3 ever did in the first 6 years of our existence cost less than $46M.

Common requirements failures?

Too many requirements – burying the development team under pure volume.

Lack of prioritization around clear and simple objectives and values.

Assuming requirements won’t change within 6 months. Not 100% turnover, mind you. But we have to accept that requirements change. It is the only way to run a business process program.

Requirements that prescribe the implementation details as well as the needs ( when you see words like “design” and “blueprint” in your requirements, you’ve probably crossed that line ).

Spending three years on requirements

Spending more than 95% of IT projects on the requirements

Failing to adopt an agile approach to allow requirements clarification to coincide with prototyping and confirmation with working software

Capturing extremely specific rules rather than the real business needs

I could go on.

A software quality group hired by the State of Texas had their own assessment of the requirements phase, arrived at with no input from BP3 on this topic:

“It was not worth the paper it was written on,” Krasner said. Deloitte was paid $46 million for that work. The initial contract was for $1.8 million, but the state kept renewing it as Deloitte continued its work.

So why does a company accept $46M in requirements development or blueprint development? Because state rules say that they can’t do both requirements and delivery. And because the money was there for the taking with no consequences. No delivery risk to Deloitte in those requirements. At 22,000 requirements, the price-per-requirement to document them was $2000. At a minimum, if there are 22,000 requirements, break it into smaller projects…

Why did Texas proceed given the advice that Krasner gave them?

Krasner says he took his concerns about the playbook to state and federal officials. Their response, he said, was, “That’s probably true.” Yet they decided to forge ahead.

What do you do when you lead the horse to water, but he won’t drink?

We can relate. More on that in another post, about choosing user interface technology for BPM projects…